[NT] RogerWilco Security Vulnerabilities

From: SecuriTeam (support_at_securiteam.com)
Date: 04/05/04

  • Next message: SecuriTeam: "[TOOL] WinBlox - Windows I/O Monitor (Full Source Code)"
    To: list@securiteam.com
    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.


    Vulnerable Systems:
     * RogerWilco version and prior
     * RogerWilco Base Station version 0.30a and prior

    Denial-of-Service vulnerability
    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.

    Privacy issues
    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.

    Flooding Attacks
    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.

    Testing Tool
    A test tool can be found at <http://aluigi.altervista.org/poc/wilco.zip>
    http://aluigi.altervista.org/poc/wilco.zip and demonstrates the
    above-mentioned issues.


    The information has been provided by <mailto:aluigi@altervista.org> 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


    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.

  • Next message: SecuriTeam: "[TOOL] WinBlox - Windows I/O Monitor (Full Source Code)"