search

QW-Group / ezquake-source

main ezQuake source code base
https://www.ezquake.com/
GNU General Public License v2.0
265 stars 122 forks source link

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

Open namtsui opened 10 months ago

namtsui commented 10 months ago

@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.

dsvensson commented 10 months ago
  • 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 commented 10 months ago

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 commented 10 months ago

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

osm commented 6 months ago

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 commented 6 months ago

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