Results 1 to 2 of 2

Thread: eDonkey 2000 ed2k: URL Buffer Overflow

  1. #1
    Senior Member
    Join Date
    Nov 2001

    eDonkey 2000 ed2k: URL Buffer Overflow

    Im not a big friend of P2P programs as edonkey etc.

    But I thought it was worth mention this vulnerability since I know that many users here at AO are using such programs .

    Source: bugtraq@securityfocus.com


    eDonkey 2000 (http://www.edonkey2000.com) is a popular peer to peer file
    sharing network with clients for Windows, Mac and Linux. One of the
    attractive features of the client is the addition of the ed2k 'virtual'
    protocol which allows for URLs which can start a download through the client
    from the network, by simply including a link on a web page. This has spawned
    a range of sites devoted to providing 'ed2k' style links to content
    available on the network. The ed2k 'protocol' simply calls 'gdonkey %1',
    where %1 is the URL being passed. The client contains a buffer overflow in
    the way it handles this argument.

    Affected Versions:

    The Windows client version 35.16.59 was shown to be vulnerable, though
    apparently 35.16.60 is also affected. No other versions were tested, though
    it is suspected that all Windows versions of eDonkey that support the ed2k:
    URL before v35.16.61 are probably affected. The links were tested in IE,
    although other browsers also have support for extended protocols and it is
    assumed the eDonkey client can be affected from these browsers as well.


    The buffer overflow can be triggered by an overly long string in the
    filename section of an 'ed2k' url. Initial experiments exposed different
    methods of overflowing the buffer with varying results, some of which
    strongly suggest that the overflow is exploitable. The following is an
    example ed2k URL which may cause a BO;

    When clicked, this URL will launch eDonkey and cause it to crash at address
    0x00414141 ('AAA'), with EBP set to 0x42424242 ('BBBB'). The top byte of EIP
    doesn't seem to be possible to set using a typical stack smash, though
    varying the length of the buffer and values can cause a wide range of
    different results. A copy of the buffer seems to always exist at around
    0x01650897, or ESP+~0xA29. The version used for testing was v35.16.59 so
    this may vary with later clients. I am yet to find a way to direct the flow
    of execution to the buffer, though I highly suspect it is possible. I would
    be interested if anyone is able to craft a method to do so.


    For the record, the eDonkey authors were quick to resolve the problem,
    releasing an upgrade within hours. The new version (v35.16.61) is available
    for download from their site (http://www.edonkey2000.com). Initial tests suggest
    that the new version is required to connect to the eDonkey network, although
    this is unconfirmed. It should be noted however that the overflow is
    possible whether or not the client is connected to the network.

    Shane Hird Research Scientist
    Distributed Systems Technology Centre

  2. #2
    Hi mom!
    Join Date
    Aug 2001
    "You must spread your AntiPoints around before giving it to micael again."
    I wish to express my gratitude to the people of Italy. Thank you for inventing pizza.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts