####################################################################### Luigi Auriemma Application: RogerWilco http://rogerwilco.gamespy.com Versions: - RogerWilco <= 1.4.1.6 - RogerWilco Base Station <= 0.30a Platforms: Windows, MacOS, Linux and FreeBSD Bugs: A] Crash with malformed UDP packet B] "Voices from the deep" bug C] Privacy problems D] Annoying attacks Exploitation: remote, versus server and client (channel broadcast) Date: 31 Mar 2004 Author: Luigi Auriemma e-mail: aluigi@autistici.org web: aluigi.org ####################################################################### 1) Introduction 2) Bugs summary 3) Bugs details 4) The Code 5) The Code examples 6) Fix ####################################################################### =============== 1) Introduction =============== RogerWilco is a voice chat application running on Windows and MacOS but are also availables dedicated servers (called "Base Stations") for Windows, Linux and FreeBSD x86. The program is distribuited 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 full of security bugs very interesting to study and this time I want to talk about some types of bugs not caused by programming errors but by how the software has been designed. To be more comprehensible this advisory/paper is divided into 2 sections, one with a quick summary of the vulnerabilities and another with all the details. ####################################################################### =============== 2) Bugs summary =============== ---------------------------------- A] Crash with malformed UDP packet ---------------------------------- A special crafted UDP packet (big and with some big values in it) sent to the UDP audio port of RogerWilco will immediately crash the server or the client. ----------------------------- B] "Voices from the deep" bug ----------------------------- Is possible for anyone to talk into a channel without being into it but simply sending the audio stream directly to the server or to a specific client inside the same channel. The audio stream will be transmitted to anyone in the channel or also only to a specific user or group of users. Only trasmission is possible, not reception. ------------------- C] Privacy problems ------------------- Both client and server report a lot of informations, the server for example shows all the IP addresses and port used by clients and clients show the server IP to which they are connected. ------------------- D] Annoying attacks ------------------- The dedicated server shows the message "nothing read from recv" when someone connects to its port 18009 and disconnects without sending data. Making a lot of empty connections the server's administrator will be flooded by these messages. The GUI application refreshs its entire window when a user enters, exits or changes his nickname. If someone changes his nickname infinitely times all the users in the same channel will have some bad effects as the impossibility to take the control of their application. ####################################################################### =============== 3) Bugs details =============== ---------------------------------- A] Crash with malformed UDP packet ---------------------------------- RogerWilco uses an UDP port for the transmission and the reception of the audio stream. Each UDP packet is composed by a first byte that is ever 0x0f and then by the name of the channel to which trasmitting the sound followed by a NULL byte. Then are located the informations about what user or users must receive the audio stream and also if must be retransmitted. The users who must 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 he joins). The last piece of the packet is the audio data block. A quick example of audio packet is the following: "\x0f" // ever 0x0f "channel\0" // name of the channel in which trasmitting the stream "\xff\xff" // this data "should" represent the type of transmission "\x7f" // as above, I don't have details (not important here) "\x00" // I don't know its usage (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 Now, RogerWilco manages the packet in the following mode: the program arrives to read until the "number of target IDs" and then starts a loop to read all the 16 bits fields after it containing the target IDs. The following is the piece of code doing that (from RWNET.DLL): :100050BF 668B06 mov ax, word ptr [esi] :100050C2 50 push eax :100050C3 E81C1D0000 Call 10006DE4 (WSOCK32.ntohs) :100050C8 8B4D58 mov ecx, dword ptr [ebp+58] :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). ----------------------------- B] "Voices from the deep" bug ----------------------------- RogerWilco is composed by a TCP and an UDP section, the first is used to manage users, nicknames, IDs, accesses and other things while the second is only used for the audio stream. The nice fact is that is not needed to join a channel (TCP section) to transmit the own audio but is only needed to send the UDP stream to the server that will manage it normally. This "structure" lets anyone to talk anonymously into any server's channel without being stopped and without limits because limits are managed in the TCP section, so for example we can put our voice in a server also if it is password protected. The only 2 small and almost unexistent limits I have found are that the data can be only sent and not received and that is needed to know the IDs of the users inside the channel to let the stream to reach them. RogerWilco supports a maximum of 127 IDs for each sound stream (look the explanation of the previous bug) so if is impossible to enter in the channel of the server to get all the real user IDs (for example because it is protected by an unknown passowrd), exists ever the possibility to use the IDs from 0 to 127 because IDs are sequentials and are ever reused so I "think" is rare to find a server with users having IDs over 127. ------------------- C] Privacy problems ------------------- When an user enters in a channel, the server immediately sends to him all the list of users inside the channel with their IDs (tag 0x0a0f), nicknames (tag 0x0c0f) and moreover their source IP addresses and ports (tag 0x0f0f). The same happens if we try to enter in a client (exactly as we do with servers because the UDP and TCP ports are EVER opened) in fact we will receive the tag 0x010f showing the IP of the server in which the user is talking. The result is that if an user is talking in a channel and don't like what another user is saying, he can easily cause damage exactly to him. ------------------- D] Annoying attacks ------------------- There is not too much to say about these so called "attacks", in fact the message "nothing read from recv" is shown into the dedicated server console when a client connects to the port 18009 and disconnects without sending data. The port 18009 is something like a mini web server showing the current channels hosted on the dedicated server and some other informations. Instead more interesting is the problem of the GUI program, in fact the tag 0x100f is used just by the users to change their nicknames while they are talking in a channel. Changing the own nickname continually will create some visualization effects to the other users because the window of the program will be recreated each time and the users cannot control the program during this boring refresh. ####################################################################### =========== 4) The Code =========== "Testing tool for RogerWilco 0.4" released: http://aluigi.org/poc/wilco.zip ####################################################################### ==================== 5) The Code examples ==================== The following are some quick and simple examples of how to test all the problems I have described in this and in the previouses advisories for RogerWilco using my proof-of-concept. "server" and "client" are the IP or the hostname of the host we wanna test (as localhost): ---------------------------------- A] Crash with malformed UDP packet ---------------------------------- wilco -10 server or wilco -10 -p 3783 server ----------------------------- B] "Voices from the deep" bug ----------------------------- wilco -9 server then we must connect our RogerWilco client to localhost:3780/CHANNEL where CHANNEL is the channel in which we wanna transmit our sound. Then we simply need to use our client normally (for example hitting F12 to talk). wilco -8 -c mychannel server this option will transmit a bad and annoying noise sound to all the users into "mychannel". ------------------- C] Privacy problems ------------------- wilco server or wilco client or wilco -p 3783 server or wilco -p 3783 -c mychannel -n yournickname server The tool will show all the informations received from the server or the client. We can also use the proxy option that can be used with a RogerWilco client to get the informations in real-time: wilco -x server ------------------- D] Annoying attacks ------------------- wilco -6 -p 3783 server and wilco -7 server or wilco -7 client ####################################################################### ====== 6) Fix ====== RogerWilco is no longer supported. #######################################################################