aMule Forum

English => en_Bugs => Topic started by: DrazziB on April 04, 2004, 04:47:59 PM

Title: eMule v0.42d DecodeBase16 Remote Buffer Overflow Vulnerability
Post by: DrazziB on April 04, 2004, 04:47:59 PM

http://www.k-otik.net/bugtraq/04.03.eMule.php [FR]

Security Bug in DecodeBase16 function.

As far as I know, aMule should be vulnerable to this security bug.

Title: Re: eMule v0.42d DecodeBase16 Remote Buffer Overflow Vulnerability
Post by: Kry on April 04, 2004, 07:03:11 PM

We have no irc ;)

thanks for the report. I got it from eMule developers too :)

Title: Re: eMule v0.42d DecodeBase16 Remote Buffer Overflow Vulnerability
Post by: DrazziB on April 04, 2004, 07:17:05 PM

Quote

Originally posted by Kry
We have no irc ;)
thanks for the report. I got it from eMule developers too :)

DecodeBase16() is also used in ExternalConn.cpp for serving WebServer HTML pages and other stufs. Not only in IRC feature :)
But I don't know if another exploit exist for the internal WebServer in aMule.

Thank for your work on aMule Kry & Delta !!!
:baby:

PS : The IRC is "THE useless feature (c)", I will never use or try, so don't implement it :D

Title: Re: eMule v0.42d DecodeBase16 Remote Buffer Overflow Vulnerability
Post by: Kry on April 04, 2004, 08:53:01 PM

Ahyeah. The webserver. I use to ignore it because it's shakraw's work ;)

I'll review it or notice shak.

Title: Re: eMule v0.42d DecodeBase16 Remote Buffer Overflow Vulnerability
Post by: Kry on April 05, 2004, 06:50:18 AM

The code is reviewed and I think it's safe. I'll notice shak anyway. Thanks again :)


P.S: yeah, IRC feature seems 'NOT NEEDED AT ALL' for me. We have plenty of irc clients on linux ;)

Title: Re: eMule v0.42d DecodeBase16 Remote Buffer Overflow Vulnerability
Post by: thepolish on April 05, 2004, 08:29:55 AM

Yes Kry, i agree ... Is IRC really needed ? vote !

the polish

Title: Re: eMule v0.42d DecodeBase16 Remote Buffer Overflow Vulnerability
Post by: fz on April 05, 2004, 05:10:32 PM

The buffer size check should be added to DecodeBase16() nonetheless.
And while we are at this: I've got a question.
From eMule 0.42e sources:

Code: [Select]

bool DecodeBase16(const char *base16Buffer, unsigned int base16BufLen, byte *buffer, unsigned int bufflen)  {
 unsigned int uDecodeLengthBase16=DecodeLengthBase16(base16BufLen);
 if (uDecodeLengthBase16 > bufflen)  
  return false;
 memset(buffer, 0, uDecodeLengthBase16);
and

Code: [Select]

unsigned int DecodeLengthBase16(unsigned int base16Length)  {
 return base16Length / 2U;
}

If I'm not completely mistaken this code may still cause a buffer overflow if base16BufLen is an odd number.
If for example base16BufLen==3 and bufflen==1, then uDecodeLengthBase16=3/2==1 (integer arithmetics) and therefore the size check doesn't trigger. The decode loop will write to buffer[0] and buffer[1] because 2 bytes are needed to decode 3 Base16 characters, but bufflen is 1 byte.

This is no problem if base16BufLen always is an even number, but I don't know if that's a valid constraint.

A fix for this would be to change  DecodeLengthBase16 to

Code: [Select]

unsigned int DecodeLengthBase16(unsigned int base16Length)  {
 return (unsigned int)ceil((float)base16Length / 2.0f);
}

Any comments on this?

Greets, fz.

EDIT:
To avoid any misunderstandings: This does not mean that eMule is still vulnerable to any exploits. An explicit size check precedes any call to DecodeBase16() (for example if (base16BufLen==32 || DecodeBase16(...))), so there's no chance to exploit.

Title: Re: eMule v0.42d DecodeBase16 Remote Buffer Overflow Vulnerability
Post by: Kry on April 05, 2004, 07:46:00 PM

You are right... will be on RC2