BUG: security: remote code execution (RCE) bug in clients < 3.6.4

[namtsui]

@dsvensson posted a video revealing that there is a remote code execution bug in ktx and ezquake.

see: https://www.youtube.com/watch?v=fho21K9EOCk

The release notes (https://github.com/QW-Group/ezquake-source/releases/tag/3.6.4) does briefly mention: DOWNLOAD: Harmonize download filter (dsvensson). The description in the youtube video states, The 3.6.4 release uses the same filter as other types of downloads so that's one step in the right direction.

This was poorly handled. It is not clear from the release notes that there is a security concern at all. This would make it easier for downstream maintainers like @tdm4 and for users to understand that it is important to upgrade.

• What is this bug? Can a malicious server admin force a shared object file to download and execute arbitrary code as shown in the video?
• What versions of ezquake / mvdsv / ktx are affected by this bug?

[dsvensson]

• What is this bug? Can a malicious server admin force a shared object file to download and execute arbitrary code as shown in the video?

Yes. I did that in the video :)

• What versions of ezquake / mvdsv / ktx are affected by this bug?

mvdsv filters the download command. Think only special admins can download files directly under /qw/* so it would take some more injection trickery to authenticate the user as such which is why I instead used FTE to serve for the demo.

I can see a scenario where the server has a simple rcon, a stufftext sets that rcon in the client and auths the user towards the server, at which point the download is stuffed, but at that point it's just easier to recompile the server code.

mvdsv and ktx have zero blame here, just made it a bit easier to do this without changing the code, thus making it a good proof of concept of a shared server where many people can upload to a /qw/* directory via ftp/sftp/http, but otherwise have no control over the server.

If you have total control of the server you can just send such stufftexts directly with any content you want, just requires compiling a new version and I wanted to limit myself to prebuilt binaries usecase.

So while this demo has a somewhat rarepepe server side setup, the fact remains that you have no idea who answers on the other side when you connect, and the vulnerability is on the client side.

[tdm4]

Wow. This looks pretty bad! Thanks @dsvensson for finding this and for @namtsui for bringing this to my attention.
I've just submitted an update for games/mvdsv to OpenBSD ports and now with the DIST_TUPLE mechanism, I can update ezquake to the latest as well.

[tdm4]

I've submitted an update to the OpenBSD ports mailing list. Hopefully it will be committed soon.

[osm]

Unfortunately, this issue persists.

Here's a video that demonstrates how a malicious server is able to remotely execute
code on the client:
https://www.youtube.com/watch?v=13Oh1960MFs

The problem is that the server can execute any command it wants on the client by
using the stufftext feature.

One way to solve this would be to implement a whitelist of commands that are
actually okay for the server to execute. I don't think that it should be necessary to
expose all commands available in the client to the server.

[dsvensson]

To be clear, this is a different mechanism than the one found before 3.6.4, but with just as severe effect.