Two security vulnerabilities in the ioquake3 engine may affect your quake3 and/or openarena packages. I will comment with more details when I have confirmed that this bug is not public.
Passing on a message from upstream developer Thilo Schulz <email@example.com>, who should be contacted for further details if required:
Dear Sir or Madam,
I am informing you about two security vulnerabilities that were recently found
by a user with the handle "devhc" in ioquake3, an open source project
dedicated to the maintenance of the dated quake3 engine, see
http://www.ioquake3.org for more information.
It is my understanding, that your distributions or games are packaging or
based on recent revisions of ioquake3.
The first bug was introduced in svn revision 1773 and does not exist in
ioquake3's last official release (version 1.36), however, several projects
that are based on more recent svn revisions of our source tree might be
afflicted, like "World of Padman".
The first bug is a shell injection vulnerability which allows server admins to
execute arbitrary shell commands on connecting clients.
It can be triggered by setting the fs_game cvar to something like
"`echo <insert 250 chars here> > inject.txt`"
This bug was fixed in revision 2097, see :
[CVE-2011-1412 has been assigned to the vulnerability fixed in r2097 -smcv]
The second bug is not as severe, but was already introduced in revision 1499,
thus ioquake3 1.36 is afflicted.
Here, a file extension check is broken and malicious game code might execute
arbitrary code outside its Virtual Machine context by writing to DLL files
that are loaded by the quake3 engine during gameplay.
This bug was fixed in revision 2098, see:
[CVE-2011-2764 has been assigned to the vulnerability fixed in r2098 -smcv]
We intend to go public with this information around Thursday noon (European
time), so please do not disclose these details until our official posting to
bugtraq or Full Disclosure.
These are bugs in the ioquake3 engine, not in particular game code. I don't know how you handle this engine in Fedora; the upstreams of various games each have their own outdated "official" ioquake3 builds, but in Debian we use a shared engine binary for OpenArena and Quake III Arena.
I believe that who is and isn't vulnerable goes like this:
engine | based on | CVE-2011-1412 | CVE-2011-2674 |
ioQuake3 1.36 | r1520 | - | vulnerable |
OpenArena engine 0.8.x-13 (0.8.5) | r1759 | - | vulnerable |
OpenArena engine 0.8.x-14 (0.8.5) | r1759 | - | vulnerable |
OpenArena engine 0.8.x-15 | r1783 | vulnerable | vulnerable |
OpenArena engine 0.8.x-16 | r1788 | vulnerable | vulnerable |
ioUrbanTerror 2007-12-20 server | r1240 | - | no check |
ioUrbanTerror 2007-12-20 client | r1142 | - | no check |
World of Padman 1.2 non-Windows | r1202 | - | no check |
World of Padman 1.2 Windows-only | r1142 | - | no check |
World of Padman first standalone | r1051 | - | no check |
Tremulous 1.1.0 | ? | - | no check |
Engines marked "no check" for CVE-2011-2674 don't have the regression from
r1499, but also don't have the check as originally added (r1405) at all, so
the only way to use them safely is to turn off auto-downloading, or not allow
native-code gamecode (or preferably, both). Engines this old probably aren't
safe to use on untrusted bytecode anyway, though.
Hans, can you help with this?
(In reply to comment #3)
> Hans, can you help with this?
Fedora is shipping ioquake3 svn r1802 in all supported releases + some patches to allow using a single ioquake3 binary with all of quake3 / openarena / UrbanTerror / World of Padman (these patches come from Debian and have been submitted upstream).
This means that what we are vulnerable to both CVE-s. I'll prepare an update for this tonight (on my local system), and commit, build, and create an update in bodhi for this as soon as this goes public.
Can you let me know the instant this goes public? Or shall I just commit the package changes to our git (thus making them public) and start the builds tomorrow (Thursday) after 11am CET ?
(In reply to comment #4)
> Can you let me know the instant this goes public?
I'll ask Thilo to cc you on the advisory.
Created attachment 515455 [details]
[1/3] backport of r2098 onto r1946
In case it helps, here's the first of three patches I'll be applying in Debian.
Created attachment 515456 [details]
[2/3] backport of r2092 onto r1946, so r2097 will apply
Created attachment 515457 [details]
[3/3] backport of r2097 onto r1946
I'm converting this into an SRT bug (so we can create appropriate Fedora trackers when public, as well as have CVE aliases, etc.).
Hans, is it correct to understand then that this _only_ affects the quake3 package? The other packages, like tremulous, depend on quake3 for the ioquake engine?
(In reply to comment #9)
> I'm converting this into an SRT bug (so we can create appropriate Fedora
> trackers when public, as well as have CVE aliases, etc.).
> Hans, is it correct to understand then that this _only_ affects the quake3
> package? The other packages, like tremulous, depend on quake3 for the ioquake
Yes and no, openarena uses the quake3 package for the ioquake3 engine, but
tremulous / tremfusion and alienarena use and ship with a fork of the ioquake3 engine.
(In reply to comment #10)
> tremulous / tremfusion and alienarena use and ship with a fork of the ioquake3
The version of Tremulous in Debian (1.1.0) is based on ioquake3, but is too old to suffer from CVE-2011-1412 (the more serious and easily-exploitable of these vulnerabilities). If your version is different, the pattern to grep for is 'system *('.
I believe Alien Arena is based on Quake *2*, possibly with some code from ioquake3 added. In any case, the version in Debian (7.51) doesn't seem to have CVE-2011-1412.
Upstream consider CVE-2011-2764 to be a less serious vulnerability. It's only significant if you allow your Q3 engine to run untrusted bytecode (either by enabling auto-downloading, or by installing untrusted mods in your home directory) *and* you allow it to run native-code DLLs (+set vm_cgame 0, +set vm_game 0, +set vm_ui 0, or Debian's patch to let bytecode be replaced by a request to load the equivalent native code so we don't rely on pre-built bytecode that we can't rebuild - I don't think you apply that particular patch in Fedora?).
In Debian's OpenArena, I'm treating -2764 as a vulnerability, due to that patch; but if you're using the unmodified bytecode in pak*.pk3, it's not exploitable under a normal configuration.
Older ioQuake3 forks like Tremulous are probably not safe to use with untrusted bytecode in any case (there have been crash bugs, although as far as I know, none are thought to be exploitable beyond DoS) so auto-downloading isn't a good idea anyway. I believe it's off by default, but can be enabled through the GUI.
Now public, http://lists.grok.org.uk/pipermail/full-disclosure/2011-July/082070.html
(In reply to comment #12)
> Now public,
Thanks for this, as well as for all your other work on this and your input wrt the (non)vulnerability of alienarena and tremulous.
Updates for this for F-14 - F-16 are on there way.
Hmm, the bug needs to be opened up for the updates system to be able to point to it. Can someone with the necessary rights please open it up now that this is public?
Sorry, this went public before I woke up. Opening it now.
Updated packages have been pushed to updates-testing for F-14 and F-15, but for some reason bodhi is not updating this bug, perhaps because this is the Security Response bug, and not the actual component bug (note no component bugs have been created for this yet).
Common Vulnerabilities and Exposures assigned an identifier CVE-2011-3012 to
the following vulnerability:
Reference: BUGTRAQ:20110728 Two security issues fixed in ioQuake3 engine
Reference: FULLDISC:20110728 Two security issues fixed in ioQuake3 engine
The ioQuake3 engine, as used in World of Padman 1.2 and earlier,
Tremulous 1.1.0, and ioUrbanTerror 2007-12-20, does not check for
dangerous file extensions before writing to the quake3 directory,
which allows remote attackers to execute arbitrary code via a crafted
third-party addon that creates a Trojan horse DLL file, a different
vulnerability than CVE-2011-2764.
(I suspect that this would be fixed with the same patch used to fix CVE-2011-2764, but I'm not sure... can someone more familiar with it check to make sure this is the case?)
(In reply to comment #17)
> (I suspect that this would be fixed with the same patch used to fix
> CVE-2011-2764, but I'm not sure... can someone more familiar with it check to
> make sure this is the case?)
This should only impact configurations where execution of native compiled (rather then the standard quake3 byte code format) game logic is allowed. We don't ship any such configurations.
Simon, can you confirm my analysis?
(In reply to comment #17)
> The ioQuake3 engine, as used in World of Padman 1.2 and earlier,
> Tremulous 1.1.0, and ioUrbanTerror 2007-12-20, does not check for
> dangerous file extensions before writing to the quake3 directory,
> which allows remote attackers to execute arbitrary code via a crafted
> third-party addon that creates a Trojan horse DLL file, a different
> vulnerability than CVE-2011-2764.
How does this differ from CVE-2011-2764, except by claiming to be different? This is exactly how you'd exploit -2764, and all of the references in Comment #17 discuss -1412 and -2764. The upstream advisory from Thilo Schulz, posted to Full Disclosure and SecurityFocus, specifically states that -2764 was allocated for what Thilo calls "Issue #2" (the one fixed in r2098).
(I can't currently reach securityfocus.com for some reason, but it seems liveweb.archive.org can... meanwhile, cve.mitre.org just gives me an error, but that seems to be normal for recent vulnerabilities.)
I obtained the two CVE IDs -1412 and -2764 from the Debian security team while helping Thilo to coordinate this advisory.
If there is a separate vulnerability not fixed in r2098, please contact me and Thilo privately.
(In reply to comment #18)
> This should only impact configurations where execution of native compiled
> (rather then the standard quake3 byte code format) game logic is allowed.
This is true for CVE-2011-2764, at least: Fedora should only be vulnerable if a user sets one of the vm_ui, vm_game or vm_cgame cvars to "0". (OpenArena in Debian was vulnerable, because we avoid using the bytecode for licensing reasons.)
I haven't seen any description of CVE-2011-3012 that explains how it differs from -2764, so I can't say anything about -3012.
(In reply to comment #19)
> (I can't currently reach securityfocus.com for some reason, but it seems
> liveweb.archive.org can... meanwhile, cve.mitre.org just gives me an error,
> but that seems to be normal for recent vulnerabilities.)
Yes, it does take some time. Even when Mitre creates descriptions, they appear on cve.mitre only after some delay. Nist's NVD site has them earlier:
> I haven't seen any description of CVE-2011-3012 that explains how it differs
> from -2764, so I can't say anything about -3012.
Looking at the full-disclosure post, and given the experience with how CVEs are split some times, this is most likely related to:
To prevent this from happening, ioquake3 introduced a file extension check
in r1499 which denied writing files with certain names. However, this check
was broken and corrected in r2098 only.
CVE-2011-3012 seems to be for "ioquake3 does not check file extensions before writing file, r1499" and CVE-2011-2764 for "previous fix for CVE-2011-3012 was incomplete and did not correctly prevent creating files with arbitrary extension, r2098". HTH
According to this Debian bug report, tremulous is also affected by these flaws:
Note that we're using Tremulous 1.2beta because 1.1 has problems running on x86_64 architecture and upstream doesn't want to fix it in version 1.1. There are no functions mentioned in second and third attached patch. I will fix just "DLL overwriting" issue from the first patch + other CVEs.
(In reply to comment #22)
> Note that we're using Tremulous 1.2beta because 1.1 has problems running on
> x86_64 architecture and upstream doesn't want to fix it in version 1.1.
(I worked around that in Debian by patching out the (broken?) x86-64 JIT and using the generic interpreter used by unsupported architectures, which seems to be OK.)
If by "1.2beta" you mean GPP1 ("gameplay preview 1"), I believe it's only vulnerable to CVE-2011-2764 (see <http://seclists.org/bugtraq/2012/Feb/118>), but please do double-check that.
CVE-2011-2764 has the mitigation that it's only a threat if you run untrusted bytecode, and if you run untrusted bytecode, you have worse problems:
(In reply to comment #11)
> Older ioQuake3 forks like Tremulous are probably not safe to use with untrusted
> bytecode in any case (there have been crash bugs, although as far as I know,
> none are thought to be exploitable beyond DoS) so auto-downloading isn't a good
> idea anyway. I believe it's off by default, but can be enabled through the GUI.
In Debian's Tremulous I've patched out auto-downloading altogether. I'm tempted to do the same in our ioquake3 packages.