Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
Luigi Auriemma has reported a vulnerability in Quake3 Engine, which can be exploited by malicious people to cause a DoS (Denial of Service). Reproducible: Always Steps to Reproduce: 1. 2. 3. Actual Results: DoS
Affected games : games-action/fakk2 games-fps/rtcw games-fps/quake3-* games-fps/enemy-territory-* ####################################################################### Luigi Auriemma Application: Quake 3 engine http://www.idsoftware.com Games: - Call of Duty <= 1.5 - Call of Duty: United Offensive <= 1.51 - Heavy Metal: F.A.K.K.2 <= 1.02 - Quake III Arena <= 1.32 - Return to Castle Wolfenstein <= 1.41 - Soldier of Fortune II: Double Helix <= 1.03 - Star Trek Voyager: Elite Force <= 1.20 - Star Trek: Elite Force II <= 1.10 - Star Wars Jedi Knight II: Jedi Outcast <= 1.04 - Star Wars Jedi Knight: Jedi Academy <= 1.011 - Wolfenstein: Enemy Territory <= 1.02 / 2.56 ...possibly others Platforms: Windows, Linux and Mac Bug: crash or shutdown caused by incorrect handling of big queries Exploitation: remote, versus server Date: 12 Feb 2005 Author: Luigi Auriemma e-mail: aluigi@autistici.org web: http://aluigi.altervista.org ####################################################################### 1) Introduction 2) Bug 3) The Code 4) Fix ####################################################################### =============== 1) Introduction =============== The Quake 3 engine is the well known game engine developed by ID Software (http://www.idsoftware.com) and is used by many games. Some months ago I reported similar problems in three games based on this engine: Medal of Honor, Call of Duty and Soldier of Fortune II. Except for Medal of Honor that is affected by a specific buffer overflow, the other two games can be "probably" included in this advisory too but I'm not totally sure. ####################################################################### ====== 2) Bug ====== The Quake 3 engine has problems to handle big queries allowing an attacker to shutdown any game server based on this engine: ERROR: Info_SetValueForKey: oversize infostring In some of the vulnerable games is also possible to crash the server. ####################################################################### =========== 3) The Code =========== http://aluigi.altervista.org/poc/q3infoboom.zip A simple scanner for testing any game based on the Quake 3 engine. ####################################################################### ====== 4) Fix ====== Only the two Call of Duty games have been fixed with the 1.5b and 1.51b patches, all the others are still vulnerable. I have released an universal patcher that limits the amount of handled data in the queries from 1023 to 767 solving the problem in any game: http://aluigi.altervista.org/patches/q3infofix.zip (only in Heavy Metal: F.A.K.K.2 is needed to reduce the amount of handled data to less than 512 instead of 767) #######################################################################
I'm on this one... I'll check upstream for proper patches tomorrow. It looks like fakk2 will require the bugfix, simply because upstream is dead.
Games team, where are we now ?
I've been pretty busy with the upcoming Gentoo release, but I've been doing some checking with upstream on those games. Since Loki Games is defunct, there is no upstream for fakk2, so it will either need to be masked, or have the below fix verified and implimented. I have been unable to verify that the games are, in fact, vulnerable, as testing time has been non-existent for me. There also does not appear to be an upstream patch in the works from Id Software on rtcw, quake3*, or enemy-territory* that I can tell, so those would have to be verified and patched, also.
This issues look similar enough to merge. (if they aren't dupes already). http://www.securityfocus.com/archive/1/394823 ####################################################################### Luigi Auriemma Application: Quake 3 engine http://www.idsoftware.com Vulnerables: - Call of Duty <= 1.5 - Call of Duty: United Offensive <= 1.51 - Quake III Arena <= 1.32 - Return to Castle Wolfenstein <= 1.41 - Soldier of Fortune II: Double Helix <= 1.03 - Star Wars Jedi Knight II: Jedi Outcast <= 1.04 - Star Wars Jedi Knight: Jedi Academy <= 1.0.1.0 - Wolfenstein: Enemy Territory <= 1.02 / 2.56 ... possibly others "Seem" safe: - Medal of Honor: Allied Assault (no effects) - Medal of Honor: Breakthrough - Medal of Honor: Spearhead - Star Trek Voyager: Elite Force (attacker only) - Star Trek: Elite Force II (attacker crash only) - Wolfenstein: Enemy Territory 2.60 (patched) Platforms: Windows, Linux and Mac Bug: bad handling of big commands/messages Exploitation: remote, versus clients (in-game) Date: 02 Apr 2005 Author: unknown, the bug has been reported to me by an admin of the game Return of Castle Wolfenstein Advisory: Luigi Auriemma e-mail: aluigi autistici org web: http://aluigi.altervista.org ####################################################################### 1) Introduction 2) Bug 3) The Code 4) Fix ####################################################################### =============== 1) Introduction =============== The Quake 3 engine is the well known game engine developed by ID Software (http://www.idsoftware.com) and is used by many games. ####################################################################### ====== 2) Bug ====== This problem is enough known in the community of the Return to Castle Wolfenstein and Enemy Territory games from many time (over one year), and this second one is actually the only game to have an official patch released just some weeks ago. An interesting explanation of this bug and a method to fix it modifying the source code of the vulnerable games (SDK) is available here: http://bani.anime.net/banimod/forums/viewtopic.php?p=27322 In short the problem is in how the engine handles the commands longer than 1022 chars, in fact they are automatically truncated at that size and the rest of the chars is handled as network data confusing the engine. If an attacker joins a server and sends a too big message any client in the server will automatically disconnect showing the "CL_ParseServerMessage: Illegible server message" error. In some games or some of their older versions could happen also a server crash, that's not caused by this bug but by other problems explained in the following advisories: http://aluigi.altervista.org/adv/jamsgbof-adv.txt http://aluigi.altervista.org/adv/codmsgboom-adv.txt Only in Soldier of Fortune II happens a clients crash instead of the simple disconnection but the game supports only the vsay_team command and so only the players in the same team of the attacker will be crashed. The problem is in-game so the attacker must have access to the server, if it is protected by password and he doesn't know the keyword or his IP/guid has been banned he cannot exploit the bug. ####################################################################### =========== 3) The Code =========== - download the following file: http://aluigi.altervista.org/poc/q3msgboom.cfg - place it in the base folder of your game (like baseq3, etmain, main, base and so on) - start a client and a server or, if possible, more clients to test better the effects of the bug - join the server - go into the console of a client (~ key or shift + ~) - type: /exec q3msgboom - any client in the server will disconnect immediately. If nothing happens or the vsay command is not supported, modify the q3msgboom.cfg file using other commands like say or vsay_team. Jedi Knight II needs that the script is executed some times before seeing the effects. ####################################################################### ====== 4) Fix ====== Currently only Enemy Territory 2.60 is officially fixed. I have tried many times in these last weeks to find an universal way to fix the bug but I had no luck, in fact the method suggested by Banimod (http://bani.anime.net/banimod/forums/viewtopic.php?p=27322) is ok but requires the recompilation of the SDK (where available). Anyway the function to modify is located in the "game" code (the name of a specific portion of the engine) that some games have built as a DLL while others as a QVM file (harder to fix and zipped in the pk3 packages) and then the binary pattern of the function changes a lot from game to game moreover because changes the G_SEND_SERVER_COMMAND value, so a binary fix based on the previously metioned patch is not possible. #######################################################################
*** Bug 87911 has been marked as a duplicate of this bug. ***
------- Additional Comment #2 From Chris Gianelloni 2005-04-04 08:37 PST ------- Well, I stabilized enemy-territory 2.60 on x86/amd64 and removed the older versions, so that one is taken care of easily enough. This would also affect quake3-ded and rtcw-ded (if we had them... ;]) so I am changing the Summary a little.
I'd say removing the ebuild for Enemy Territory for 2.56 was a very bad idea. ET 2.60 is incompatible with ETPro, which is used by most of the Enemy Territory servers. ETPro 3.0 fixed the flaw mentioned in this bug, so most of the players were already unaffected by this. There are no servers running 2.60, so no one can play Enemy Territory 2.60! According to server statistics from games-util/xqf, there are currently 1988 servers of which 1879 are running ET 2.56 and 109 servers with ETPro ETTV. 1704 servers use ETPro 3.0 or later.
ETPro is not a requirement for running Enemy Territory. This means our version of Enemy Territory was vulnerable. I have exactly 3 choices in this situation. #1. Mask the package for later removal or pending a possible vendor fix #2. Remove the package entirely #3. Upgrade the package to the vendor-supplied fixed version I chose #3 since it is the proper way to resolve such an issue, as #1 and #2 are not valid, as there is a vendor fix available. If that fixed version no longer works with an external modification, that is between the vendor and the mod maker, not me. I play this game myself and have had 0 problems finding games using 2.60 using the built-in server browser. I stand by my choice 100% and have no intentions on reversing that decision as there is no way to patch the older version to resolve both of these issues without requiring an optional package be installed that is not a requirement of the game.
I understand your reasons for unmasking the Enemy Territory 2.60 ebuild, but I don't like the fact that now Gentoo users cannot access 1700 servers which are unaffected by this flaw. Gentoo users can access 630 servers, but there aren't many good players there, because clanmatches are played with ETPro. (I found ET 2.60 servers when I discovered that xqf shows servers for one version at time.)
Look at comment #5 again. This is actually 2 bugs, one server-side and one client-side. It doesn't matter if the server is fixed if the client is not. I did the right thing to resolve this bug regarding Enemy Territory. Not liking it is not an excuse for leaving software in the tree with known remotely-exploitable holes.
Chris: Is there anything left to do to close this one, like masking unfixed packages or still waiting for some upstream to release patches ?
I was hoping upstream would do something about these, but it doesn't look like it is going to happen any time soon. games-action/fakk2 games-fps/rtcw games-fps/quake3-* These can still be exploited by the server exploit, as far as I know. I honestly have not had time to test the bug or the reported fix on them. games-fps/rtcw games-fps/quake3-* These are most likely still vulnerable to the client-side bug, provided they were vulnerable to begin with on Linux. I have not had time to test them, nor is there any fix available for these. What should we do here? I will mask the packages if that is the necessary course of action.
If both bugs are crash-only (as they look like to be) and no remote exploitation can result of this, I think removing the games won't cure the problem (which is you can't play reliably with them). These could be considered more as known defects (bugs) than security issues... So I would just add an ewarning in the ebuild that those are affected by known DOS issues that are unfixed upstream, and live with it. In that case we wouldn't be doing a GLSA about it. If your understanding of the problem is that one (or both) these issues can be abused to execute code, then we should mask them and release a masking GLSA explaining why.
They are both DoS bugs that either crash the client/server or simply cause the client to be booted from the server. If we're calling these bugs, then I'd say just reassign it to games@ as such and I'll take care of it.
My position would be to inform the user of that known defect, so that they know not to rely too much on it. A warning in the ebuild is enough for me, if you add that to the still-affected ebuilds we can close this as FIXED...
I'll get on it today if vapier doesn't beat me to it.
Chris/vapier: did any of you do it ?
I'd forgotten about it, but did it just now. =]
OK so this is resolved/cantfix using a warning in the affected ebuilds.
since the src for quake3 has been released, the issue has been fixed ... the ebuild for that is in #104106
