Bug 725951 (CVE-2011-1412, CVE-2011-2764, CVE-2011-3012) - CVE-2011-1412 CVE-2011-2764 CVE-2011-3012 quake3: arbitrary code execution vulnerabilites in ioquake3
Summary: CVE-2011-1412 CVE-2011-2764 CVE-2011-3012 quake3: arbitrary code execution vu...
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2011-1412, CVE-2011-2764, CVE-2011-3012
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 796362
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-07-27 07:12 UTC by Simon McVittie
Modified: 2021-10-19 21:49 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-10-19 21:49:45 UTC
Embargoed:


Attachments (Terms of Use)
[1/3] backport of r2098 onto r1946 (2.34 KB, patch)
2011-07-27 09:44 UTC, Simon McVittie
no flags Details | Diff
[2/3] backport of r2092 onto r1946, so r2097 will apply (4.75 KB, patch)
2011-07-27 09:45 UTC, Simon McVittie
no flags Details | Diff
[3/3] backport of r2097 onto r1946 (7.31 KB, patch)
2011-07-27 09:45 UTC, Simon McVittie
no flags Details | Diff

Description Simon McVittie 2011-07-27 07:12:24 UTC
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.

Comment 1 Simon McVittie 2011-07-27 07:16:48 UTC
Passing on a message from upstream developer Thilo Schulz <thilo>, 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 :
http://svn.icculus.org/quake3?view=rev&revision=2097

[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:
http://svn.icculus.org/quake3?view=rev&revision=2098

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

Comment 2 Simon McVittie 2011-07-27 07:20:27 UTC
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.

Comment 3 Rahul Sundaram 2011-07-27 07:46:09 UTC
Hans,  can you help with this?

Comment 4 Hans de Goede 2011-07-27 09:01:52 UTC
(In reply to comment #3)
> Hans,  can you help with this?

Yes :)

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.

Simon,

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 ?

Regards,

Hans

Comment 5 Simon McVittie 2011-07-27 09:34:58 UTC
(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.

Thanks,
    S

Comment 6 Simon McVittie 2011-07-27 09:44:17 UTC
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.

Comment 7 Simon McVittie 2011-07-27 09:45:02 UTC
Created attachment 515456 [details]
[2/3] backport of r2092 onto r1946, so r2097 will apply

Comment 8 Simon McVittie 2011-07-27 09:45:26 UTC
Created attachment 515457 [details]
[3/3] backport of r2097 onto r1946

Comment 9 Vincent Danen 2011-07-27 22:54:55 UTC
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?

Comment 10 Hans de Goede 2011-07-28 08:56:07 UTC
(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
> engine?

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.

Comment 11 Simon McVittie 2011-07-28 09:53:29 UTC
(In reply to comment #10)
> tremulous / tremfusion and alienarena use and ship with a fork of the ioquake3
> engine

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.

Comment 13 Hans de Goede 2011-07-28 14:23:20 UTC
Hi,

(In reply to comment #12)
> Now public,
> http://lists.grok.org.uk/pipermail/full-disclosure/2011-July/082070.html

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.

Regards,

Hans

Comment 14 Hans de Goede 2011-07-28 14:46:53 UTC
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?

Thanks,

Hans

Comment 15 Vincent Danen 2011-07-28 14:56:50 UTC
Sorry, this went public before I woke up.  Opening it now.

Comment 16 Hans de Goede 2011-07-31 08:02:59 UTC
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).

Comment 17 Vincent Danen 2011-08-09 22:42:55 UTC
Common Vulnerabilities and Exposures assigned an identifier CVE-2011-3012 to
the following vulnerability:

Name: CVE-2011-3012
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3012
Assigned: 20110809
Reference: BUGTRAQ:20110728 Two security issues fixed in ioQuake3 engine
Reference: http://www.securityfocus.com/archive/1/archive/1/519051/100/0/threaded
Reference: FULLDISC:20110728 Two security issues fixed in ioQuake3 engine
Reference: http://archives.neohapsis.com/archives/fulldisclosure/2011-07/0338.html
Reference: https://bugzilla.redhat.com/show_bug.cgi?id=725951
Reference: http://www.securityfocus.com/bid/48915
Reference: XF:ioquake-gamecode-code-execution(68870)
Reference: http://xforce.iss.net/xforce/xfdb/68870

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?)

Comment 18 Hans de Goede 2011-08-10 07:19:56 UTC
(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?

Comment 19 Simon McVittie 2011-08-10 09:01:14 UTC
(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.

Comment 20 Tomas Hoger 2011-08-10 09:21:44 UTC
(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:

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-2764
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-3012

> 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

Comment 21 Vincent Danen 2012-02-22 18:21:29 UTC
According to this Debian bug report, tremulous is also affected by these flaws:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660827

Comment 22 Jan Kaluža 2012-02-23 08:35:58 UTC
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.

Comment 23 Simon McVittie 2012-02-23 08:59:59 UTC
(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.


Note You need to log in before you can comment on or make changes to this bug.