[NT] Broadcast Buffer Overflow and Server Freeze in RogerWilco
From: SecuriTeam (support_at_securiteam.com)
Date: 07/02/03
- Previous message: SecuriTeam: "[NT] Information Disclosure Vulnerability in the ShareMailPro"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
To: list@securiteam.com Date: 2 Jul 2003 19:08:27 +0200
The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
Beyond Security in Canada
Toronto-based Sunrays Technologies is now Beyond Security's representative in Canada.
We welcome ISPs, system integrators and IT systems resellers
to promote the most advanced vulnerability assessment solutions today.
Contact us at 416-482-0038 or at canadasales@beyondsecurity.com
- - - - - - - - -
Broadcast Buffer Overflow and Server Freeze in RogerWilco
------------------------------------------------------------------------
SUMMARY
<http://www.rogerwilco.com/> RogerWilco is probably the most famous tool
that lets gamers to speak together during the matches with their preferred
games. It is shareware and is developed by GameSpy. Two vulnerabilities in
the product allow attackers to cause the client to crash (while executing
arbitrary code), and the server to freeze.
DETAILS
Vulnerable systems:
* RogerWilco version 1.4.1.1d3 and prior
Immune systems:
* RogerWilco version 1.4.1.2
Broadcast Buffer Overflow
This bug is just the perfect situation to make tons of damage using the
minimum energy. Until now Auriemma has never found a "broadcast" buffer
overflow, so Auriemma was very interested about it.
This buffer overflow happens when a client that connects to the server
sends a nickname string that is too long (a classical buffer overflow).
The nickname must be at least 516 bytes long to overwrite the return
address of EVERY client that receive this nickname.
In fact the server (both normal and dedicated server) will send the
nickname field in broadcast to ALL the clients connected to it. That mean
that ALL the clients connected to the server (the graphical program become
both server and client when hosts a channel) will execute the malicious
code in the nickname field sent by the attacker!
Now a bit of assembly for those that are interested in the details:
The vulnerable function starts at offset 0x40a1b0 of roger.exe. The
instructions that cause the overwriting of the return address are the
following:
:0040A200 8BF7 mov esi, edi
:0040A202 8B7C2414 mov edi, dword ptr [esp+14]
:0040A206 C1E902 shr ecx, 02
:0040A209 F3A5 repz movsd
:0040A200 ESI will point to the beginning of the nickname sent by the
client ("aaaaaaaaaaaaaaaaaaaaaa...")
:0040A202 now the address of the destination buffer will be copied
into EDI register
:0040A206 the size of the data will be divided for 4 (it copies 32
bits each time)
:0040A209 it copies the bytes that starts at the address pointed by
ESI to the new buffer overwriting the return address stored
at offset 0x0068f080 (the right return address stored before
the BoF was 0x00409304)
When RogerWilco executes the instruction at offset 0x0040A209 the return
address stored at offset 0x0068f080 will be fully overwritten.
Server Freeze
A client can connect to the server that hosts a channel and instead of
sending a full packet it sends it partially. The "join-packet" contains
all the data of the client as the channel it wants to join to, the
password for the channel, its nickname and some other little information.
The problem happens when the client uses the nickname tag ("\x0f\x10") BUT
doesn't complete the packet with all the other needed information. An
example is the following packet:
"\x0f\x00"
"\x00\x14"
"\x6a\xd6\x4c\x03\x96\xed\x3b\xe7\x88\xe2\xa9\x74"
"channel\0"
"\x0f\x10"
<-- here there is nothing!
As you can see there is nothing after the nickname tag. The problem
happens in NETWORK.DLL when the program calls the function WSOCK32.recv:
---
:100027B1 51 push ecx
* Reference To: WSOCK32.recv, Ord:0010h
|
:100027B2 E8BF440000 Call 10006C76
:100027B7 CC int 03
---
In fact the recv() function will NOT return until the malicious client is
connected to the server (probably because it waits the other pieces of
data that the attacker has not sent).
Once the attacker disconnects itself, the situation returns normally.
Exploit code:
Auriemma Luigi has written a program that tests the 2 bugs he found. You
can choose your nickname, the channel to join, the password to use, the
port to connect to, an auto-rejoin option (so you can rejoin infinitely),
get remote information and naturally you can also see what happens in
real-time on the server, as who enters, who exits, their IP addresses, who
changes his nickname, etc.
Naturally, as almost all Auriemma Luigi's tools, it can be compiled on
both UNIX and Windows: <http://www.pivx.com/luigi/poc/wilco.zip>
http://www.pivx.com/luigi/poc/wilco.zip
Fix:
RogerWilco supports the auto-update feature so you should already have the
patched version, in any case the latest (1.4.1.2) released 16th June 2003
is available on the official homepage: <http://www.rogerwilco.com>
http://www.rogerwilco.com
ADDITIONAL INFORMATION
The information has been provided by <mailto:aluigi@pivx.com> Auriemma
Luigi.
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.
- Previous message: SecuriTeam: "[NT] Information Disclosure Vulnerability in the ShareMailPro"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
