[NT] RogerWilco Security Vulnerabilities
From: SecuriTeam (support_at_securiteam.com)
To: firstname.lastname@example.org Date: 5 Apr 2004 13:58:54 +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
The SecuriTeam alerts list - Free, Accurate, Independent.
Get your security news from a reliable source.
- - - - - - - - -
RogerWilco Security Vulnerabilities
<http://rogerwilco.gamespy.com> RogerWilco is a voice chat application
running on Windows and MacOS but are also available dedicated servers
(called "Base Stations") for Windows, Linux and FreeBSD x86. The program
is distributed by GameSpy, is no longer supported and is affected by some
critical security bugs but is also still used by a lot of people.
RogerWilco is susceptible to a remote DoS, performed using a malformed UDP
packet, information disclosure and flooding.
* RogerWilco version 126.96.36.199 and prior
* RogerWilco Base Station version 0.30a and prior
A specially crafted UDP packet will crash RogerWilco (either client or
server). The packet has to be big or to have some big values as lengths in
it. The UDP port is used for the audio channel. Each UDP packet contains a
first byte that is always 0x0F and then the name of the channel to which
transmitting the sound followed by a NULL byte. Afterwards the information
on the hosts receiving the data is stored. The users who receive the data
(forwarded by the server) are listed using fields of 16 bits that contain
their IDs (each user receives an ID assigned by the server when joining).
The last piece of the packet is the audio data block.
An example of an audio packet follows:
"\x0f" // ever 0x0f
"channel\0" // name of the channel in which transmitting the stream
"\xff\xff" // this data "should" represent the type of transmission
"\x7f" // (not important here)
"\x00" // (not important here)
"\x01" // number of target IDs (server excluded), max 127
"\x00\x00" // ID 0, it is the server's ID (who must receive the data)
"\x00\x01" // ID 1, the user with ID 1 (who must receive the data)
"data..." // audio stream
When RogerWilco receives a packet it will parse it in the following
manner: It will read the number of ID's and then run in a loop and read
the 16 bit IDs. Following is the code that performs this:
:100050BF 668B06 mov ax, word ptr [esi]
:100050C2 50 push eax
:100050C3 E81C1D0000 Call 10006DE4 (WSOCK32.ntohs)
:100050C8 8B4D58 mov ecx, dword ptr
:100050CB 83C602 add esi, 00000002
:100050CE 66890479 mov word ptr [ecx+2*edi], ax
:100050D2 8B442418 mov eax, dword ptr [esp+18]
:100050D6 47 inc edi
:100050D7 3BF8 cmp edi, eax
:100050D9 7CE4 jl 100050BF
If an attacker sends a big channel name (as 924 chars) specifying the
presence of 127 IDs BUT without adding them to the packet, the program
will read from a non allocated memory zone (ESI pointer). In the dedicated
server the crash happens at offset 100050BF of RWNET.DLL while in the GUI
program it happens at offset 1000544B of NETWORK.DLL (the vulnerable
instructions are the same).
Voices from the Deep design flaw
It's possible for anyone to intervene in the audio channel without even
being part of the session. An attacker can send audio data by just knowing
which audio channel to use. The audio data will be transmitted to all
users or to a specific user in the channel if so desired. Only
transmission is possible however, not reception of data.
RogerWilco uses a TCP and UDP connections. The first is used to manage
users, nicknames, IDs, accesses and others, while the second is only used
for the audio stream itself. Due to a design flaw it isn't needed to join
the channel itself (using TCP) but only to send the UDP audio data
directly to the server. Since limits and protection is enforced via the
TCP session management of the server, sending UDP audio data directly to
the server effectively removes those limits (for sending only). The only
caveat is that the attacker has to know the IDs of the users in order to
send audio data to them.
Both client and server disclosure a lot of information about the hosts
participating in the session, such as their IPs and port numbers. When a
user joins a channel the server automatically sends all other users' IP
addresses, port numbers (tag 0x0f0f), IDs (tag 0x0a0f) and nicknames (tag
0x0c0f). Also, it's possible to receive this information without even
joining the channel.
The dedicated server shows the message "nothing read from recv" when
someone connects to port 18009 and disconnects without sending data.
Making a lot of empty connections will cause the server's administrator to
be flooded by these messages. The GUI application refreshes its entire
window when a user enters, exits or changes his nickname. If someone
changes his nickname very quickly, all the users in the same channel will
suffer DoS because of the rapid change in information on the server.
Port 18009 is sort of a mini web server showing statistics about the
server such as channels hosted and other various pieces of information.
More interesting is how the GUI is written. The GUI window recreates
whenever information (such as user nicknames) changes. A malicious user
changing a nickname rapidly will cause problems for all other users that
can't control their application when the GUI refreshes itself.
The information has been provided by <mailto:email@example.com> 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: firstname.lastname@example.org
In order to subscribe to the mailing list, simply forward this email to: email@example.com
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.