SecurityTracker.com
    Home    |    View Topics    |    Search    |    Contact Us    |   

SecurityTracker
Archives


 


Category:   Application (Generic)  >   ENet Vendors:   Salzman, Lee
ENet Packet Processing Bugs Let Remote Users Deny Service
SecurityTracker Alert ID:  1015767
SecurityTracker URL:  http://securitytracker.com/id/1015767
CVE Reference:   GENERIC-MAP-NOMATCH   (Links to External Site)
Date:  Mar 14 2006
Impact:   Denial of service via network
Exploit Included:  Yes  

Description:   Luigi Auriemma reported a vulnerability in ENet. A remote user can cause denial of service conditions.

A remote user can supply a packet with a specially crafted 'header.commandLength' parameter to cause a memory access error. The application will crash.

A remote user can also supply specially crafted fragments such that the size of the reassembled message will exceed the amount of memory available, causing the application to crash.

Some demonstration exploit code is available at:

http://aluigi.altervista.org/poc/enetx.zip

Impact:   A remote user can cause the application to crash.
Solution:   No solution was available at the time of this entry.
Vendor URL:  enet.bespin.org/ (Links to External Site)
Cause:   Access control error, Exception handling error
Underlying OS:  Linux (Any), UNIX (Any), Windows (Any)

Message History:   None.


 Source Message Contents

Subject:  Multiple vulnerabilities in ENet library (Jul 2005)


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

                             Luigi Auriemma

Application:  ENet library
              http://enet.bespin.org
Versions:     <= Jul 2005 (it's the current CVS version)
Platforms:    Windows, *nix, *BSD and more
Bugs:         A] invalid memory access (32 bit)
              B] allocation abort with fragment
Exploitation: remote
Date:         12 Mar 2006
Author:       Luigi Auriemma
              e-mail: aluigi@autistici.org
              web:    http://aluigi.altervista.org


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


1) Introduction
2) Bugs
3) The Code
4) Fix


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

===============
1) Introduction
===============


ENet is a powerful open source library for handling UDP connections (it
can be defined almost a sort of TCP over UDP).
It's very used in some games and engines like Cube, Sauerbraten,
Duke3d_w32 and others.


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

=======
2) Bugs
=======

---------------------------------
A] invalid memory access (32 bit)
---------------------------------

ENet uses 32 bit numbers for almost all the parameters in its packets,
like fragments offset, data size, timestamps, challenge numbers and so
on.
Each packet received by the library (enet_host_service) is handled by
the enet_protocol_handle_incoming_commands function.
This function uses a pointer (currentData) which points to the current
command, each packet can contain one or more commands which describe
operations like a connection request, an acknowledge, a fragment, a
message and more.
The instruction which checks this pointer to avoid that it points over
the received packet can be eluded through a big (negative on 32 bit
CPU) header.commandLength parameter.
After having bypassed the check currentData will point to an invalid
zone of the memory and when the cycle will continue on the subsequent
command (commandCount must be major than one) the application will
crash.
64 bit CPUs should be not vulnerable.

>From enet_protocol_handle_incoming_commands in protocol.c:
    ...
    currentData = host -> receivedData + sizeof (ENetProtocolHeader);
  
    while (commandCount > 0 &&
           currentData < & host -> receivedData [host -> receivedDataLength])
    {
       command = (ENetProtocol *) currentData;

       if (currentData + sizeof (ENetProtocolCommandHeader) > & host -> receivedData [host -> receivedDataLength])
         return 0;

       command -> header.commandLength = ENET_NET_TO_HOST_32 (command -> header.commandLength);

       if (currentData + command -> header.commandLength > & host -> receivedData [host -> receivedDataLength])
         return 0;

       -- commandCount;
       currentData += command -> header.commandLength;
    ...


---------------------------------
B] allocation abort with fragment
---------------------------------

ENet supports also the handling of fragments used to build the messages
bigger than the receiver's MTU.
When a fragment is received the library allocates the total message
size in memory so it can easily rebuild all the subsequent fragments in
this buffer.
If the total data size specified by the attacker cannot be allocated,
the library calls abort() and all the program terminates.

>From enet_protocol_handle_send_fragment in protocol.c:
    ...
       startCommand = enet_peer_queue_incoming_command (peer, 
                                                        & hostCommand, 
                                                        enet_packet_create (NULL, totalLength, ENET_PACKET_FLAG_RELIABLE),
                                                        fragmentCount);


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

===========
3) The Code
===========


http://aluigi.altervista.org/poc/enetx.zip


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

======
4) Fix
======


No fix.
No reply from the developers.


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


--- 
Luigi Auriemma
http://aluigi.altervista.org
 
 


Go to the Top of This SecurityTracker Archive Page





Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2019, SecurityGlobal.net LLC