eDonkey 2000 ed2k: URL Buffer Overflow

["Shane Hird" <shird () dstc edu au>]

Background:

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.

Exploit:

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;

<A
href="ed2k://|file|QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ
QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ
QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ
QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQBBBBAAA|1|11111111111111111111111111111111
|">Ed2k Buffer Overflow</A>

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.

Resolution:

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 (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