Date: Mon, 18 Aug 2003 22:26:15 +0200
From: Stefan Esser <s.esser@...atters.de>
To: bugtraq@...urityfocus.com
Subject: Advisory 02/2003: emule/xmule/lmule vulnerabilities


                           e-matters GmbH
                          www.e-matters.de

                      -= Security  Advisory =-



     Advisory: eMule/lmule/xmule multiple remote vulnerabilities
 Release Date: 2003/08/17
Last Modified: 2003/08/17
       Author: Stefan Esser [s.esser@...atters.de]

  Application: eMule <= 0.29c
               xmule <= 1.4.3, <= 1.5.6a
               lmule <= 1.3.1
     Severity: Several vulnerabilities within emule and its unix ports
               allow remote compromise of p2p users.
         Risk: Critical
Vendor Status: eMule Vendor has released a bugfixed version.
               (no solution for lmule, because no support anymore
               (no 100% solution for xmule)
    Reference: http://security.e-matters.de/advisories/022003.html


Overview:

   eMule and its unix ports are the most famous filesharing clients which 
   are based on the eDonkey2000 network. The estimated usercount reaches
   from 1 million to even 10 million p2p clients (according to a mldonkey
   statistic). With such a large userbase eMule is not only a thorn in the
   side of the music and movie industry but also an attractive target for
   script kids or worm writers. And indeed auditing the source code revealed
   vulnerabilities which can be abused to disturb the eMule network or to
   takeover other client machines.
   
   
Details:
   
   The eMule source code is object oriented which makes security auditing
   from my point of view a lot harder because the flow of execution is not
   obvious and it is first needed to get a general overview of the objects
   and their dependencies. 

   While auditing the source code following bugs where discovered

   1) OP_SERVERMESSAGE Format String Vulnerability         
      
      emule <= 0.29a
      xmule <= 1.4.3, <= 1.5.4
      lmule <= 1.3.1

      When the client receives a message from the server it passes this 
      message to a function that expects a format string argument. This 
      could be used by a malicious server to crash or takeover the 
      connected client system.


   2) OP_SERVERIDENT Heap Overflow                         
      
      emule <= 0.29a
      xmule <= 1.4.3, <= 1.5.4
      lmule <= 1.3.1

      When receiving a serverident packet from the server it is parsed in
      an unsafe manner that could lead to an exploitable heap overflow. 
      Again this allows a malicious server to crash or takeover the 
      connected client.


   3) Servername Format String Vulnerabilities             
      
      emule <= 0.29c
      xmule <= 1.4.2, <= 1.5.5
      lmule <= 1.3.1
      
      Several ways of adding a server with a name that contains format 
      string specifiers could crash the client. Remote code execution 
      through this bug is unlikely because only very short servernames 
      are accepted.


   4) AttachToAlreadyKnown Object Destruction Vulnerability 
       
      emule <= 0.29c
      xmule <= 1.4.2, <= 1.5.6a
      lmule <= 1.3.1

      When the client receives a special sequence of packets an 
      error situation can be triggered where the currently used 
      client object is deleted. This is similar to an ordinary
      double free vulnerability with the exception that here a whole
      object is mistakenly freed and still used. Because this hole
      was proven to be exploitable (remote code execution) and the 
      same packets are completely legal for other clients (no IDS 
      signature can be created anyway), I am not going into details 
      how to trigger the bug. There are just too many vulnerable 
      systems out there.


Proof of Concept:

   e-matters is not going to release an exploit for this vulnerability to
   the public. The developed exploit is considered extremly dangerous 
   because it uses a technique that allows to exploit this kind of double
   free bugs on Windows 2K/XP systems without version or binary dependant
   offsets.
   
   DCOM has shown again how devestating windows overflows are. Which is
   caused by not patching users on the one hand and on the other hand by
   an unsecure windows design that allows to exploit most vulnerabilities
   with very few or without system dependant offsets.
  

Disclosure Timeline:

   26. July 2003   - First contact to emule and xmule Vendors.
                     (xmule email bounced back after some time)
   29. July 2003   - emule vendor has verified and fixed the bugs. 
                     New version is in betatests.
   31. July 2003   - contact with xmule vendor establised.
   02. August 2003 - xmule 1.5.6a (unstable) was released by the
                     xmule vendor. This version fixes only (3).
   11. August 2003 - xmule 1.4.3 (stable) was released by the xmule
                     vendor. I mailed the vendor the same day, that
                     it only fixes (3) and (4) while the first two
                     are not fixed. No reaction yet.
   17. August 2003 - emule vendor released version 0.30a which fixes
                     all security bugs. Their changelog does not
                     underline the importance of the update and is
                     incorrectly stating problem (4) as only a 
                     crashbug.


Recommendation:

   It is very important that word about this vulnerability is spread fast
   in the eMule community, because P2P users are usually not reading 
   security mailinglists and will therefore be very slow in upgrading to new
   versions of their favourite tools. If you connect to the network you can 
   still see a huge amount of very old clients.
   
   And I hope the pressure of the xmule community can force the release
   of an 100% fixed version.

   I hope I do not need to remember the P2P users that the RIAA repeatetly
   asked for the right to hack into their PCs.
   
   
GPG-Key:

   http://security.e-matters.de/gpg_key.asc
    
   pub  1024D/75E7AAD6 2002-02-26 e-matters GmbH - Securityteam
   Key fingerprint = 43DD 843C FAB9 832A E5AB  CAEB 81F2 8110 75E7 AAD6


Copyright 2003 Stefan Esser. All rights reserved.


-- 

--------------------------------------------------------------------------
 Stefan Esser                                        s.esser@...atters.de
 e-matters Security                         http://security.e-matters.de/

 GPG-Key                gpg --keyserver pgp.mit.edu --recv-key 0xCF6CAE69 
 Key fingerprint       B418 B290 ACC0 C8E5 8292  8B72 D6B0 7704 CF6C AE69
--------------------------------------------------------------------------
 Did I help you? Consider a gift:            http://wishlist.suspekt.org/
--------------------------------------------------------------------------

Powered by blists - more mailing lists