bugtraq - Gamespy3d <= 263015 lets code execution through long IRC answer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date: Tue, 30 Sep 2003 16:56:33 +0000
From: Luigi Auriemma <aluigi@...ervista.org>
To: bugtraq@...urityfocus.com
Cc: vulnwatch@...nwatch.org, list@...ield.org, news@...uriteam.com
Subject: Gamespy3d <= 263015 lets code execution through long IRC answer

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

                             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@...ervista.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