aMule Forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

We're back! (IN POG FORM)

Author Topic: eMule v0.42d DecodeBase16 Remote Buffer Overflow Vulnerability  (Read 3954 times)

DrazziB

  • Approved Newbie
  • *
  • Karma: 0
  • Offline Offline
  • Posts: 8
    • http://www.drazzib.com/

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.
« Last Edit: April 04, 2004, 05:00:02 PM by DrazziB »
Logged

Kry

  • Ex-developer
  • Retired admin
  • Hero Member
  • *****
  • Karma: -665
  • Offline Offline
  • Posts: 5795
Re: eMule v0.42d DecodeBase16 Remote Buffer Overflow Vulnerability
« Reply #1 on: April 04, 2004, 07:03:11 PM »

We have no irc ;)

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

DrazziB

  • Approved Newbie
  • *
  • Karma: 0
  • Offline Offline
  • Posts: 8
    • http://www.drazzib.com/
Re: eMule v0.42d DecodeBase16 Remote Buffer Overflow Vulnerability
« Reply #2 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
Logged

Kry

  • Ex-developer
  • Retired admin
  • Hero Member
  • *****
  • Karma: -665
  • Offline Offline
  • Posts: 5795
Re: eMule v0.42d DecodeBase16 Remote Buffer Overflow Vulnerability
« Reply #3 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.
Logged

Kry

  • Ex-developer
  • Retired admin
  • Hero Member
  • *****
  • Karma: -665
  • Offline Offline
  • Posts: 5795
Re: eMule v0.42d DecodeBase16 Remote Buffer Overflow Vulnerability
« Reply #4 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 ;)
Logged

thepolish

  • Hero Member
  • *****
  • Karma: 2
  • Offline Offline
  • Posts: 896
Re: eMule v0.42d DecodeBase16 Remote Buffer Overflow Vulnerability
« Reply #5 on: April 05, 2004, 08:29:55 AM »

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

the polish
Logged
Only after the last tree has been cut down
Only after the last river has been poisoned
Only after the last fish has been caught
Only then you will find out that money cannot be eaten
(Cree Prophecy)

fz

  • Approved Newbie
  • *
  • Karma: 0
  • Offline Offline
  • Posts: 27
Re: eMule v0.42d DecodeBase16 Remote Buffer Overflow Vulnerability
« Reply #6 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.
« Last Edit: April 05, 2004, 05:21:01 PM by fz »
Logged

Kry

  • Ex-developer
  • Retired admin
  • Hero Member
  • *****
  • Karma: -665
  • Offline Offline
  • Posts: 5795
Re: eMule v0.42d DecodeBase16 Remote Buffer Overflow Vulnerability
« Reply #7 on: April 05, 2004, 07:46:00 PM »

You are right... will be on RC2
Logged