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
