Gamespy3d <= 263015 lets code execution through long IRC answer

[Luigi Auriemma <aluigi@altervista.org>]

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

                             Luigi Auriemma

Application:  Gamespy 3d
              http://www.gamespy3d.com
Versions:     <= 263015
Platforms:    Windows
Bug:          Code execution through memory corruption caused by long
              data from IRC server
Risk:         Medium
Author:       Luigi Auriemma
              e-mail: aluigi@altervista.org
              web:    http://aluigi.altervista.org


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


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


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

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


Gamespy3d is a commercial application developed by Gamespy to have
access to the master servers based on their protocol and to make other
things like chat for example.



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

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


Gamespy3d has a built-in IRC client to let users to join an IRC server
specified by them and starting to chat.
After sending the USER and NICK commands, the Gamespy3d client waits an
answer from the server.
If the server sends an answer of at least 262 bytes, the client will
badly interpretate the input and the execution flow will continue from
the address pointed by the 4 bytes at the offset 204 of the answer.


The following is a practical example:


: [203 bytes] [4 bytes] [54 bytes]
| |           |         |
| |           |         are needed at least 54 bytes to exploit the bug
| |           execution flow will continue by the address pointed here
| these bytes are needed
IRC protocol



However what happens in the program is not totally clear. The last
instruction before the exception in the version 263010 of the program
is:

:004F29CB 8378F401       cmp dword ptr [eax-0C], 00000001


Then the execution flow continue directly from the address pointed by
the 4 bytes in the server's answer.
EAX and EBX instead will point to the 4 bytes before (useful for
exploitation).


The following is the list of the bytes that cannot be used or that will
be converted in NULL bytes:

0a = cannot be used
0d = cannot be used
20 = cannot be used
21 = will be converted in 0x00
40 = will be converted in 0x00
7e = will be converted in 0x00




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

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


You can use a text file containing the long string launching netcat in
listening mode:

nc -l -p 6667 -v -v -n < long_string.txt



Or you can use my simple proof-of-concept:

http://aluigi.altervista.org/poc/gs3dirc.zip



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

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


Gamespy was notified but I have received no answers.



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


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