PDA

Bekijk Volledige Versie : AOL AIM Instant Messenger Buddy Icon "ateimg32.dll" DoS



Tom Ferris
07/06/05, 21:45
AOL AIM Instant Messenger Buddy Icon "ateimg32.dll" DoS

Release Date:
June 6, 2005

Date Reported:
June 6, 2005

Severity:
Medium? (if you can exploit it, email me. ;-])

Vendor:
AOL

Systems Affected:
AIM 5.9.3797 for Windows 98/ME/2K/XP (5.96 MB) and all prior versions.

Affected Platforms:
# Windows

Overview:
A denial of service (its on the heap) vulnerability exists within the
AOL AIM instant messenger. Here is a description of AIM from the vendor:

"Enjoy the convenience of using your AIM screen name as your e-mail
address-and take advantage of new and improved features, like:
• Spam and Anti-Virus Protection: Industry-leading security tools help
keep your mailbox free of annoying junk mail and harmful viruses."

Security? Anti-Virus? nice... ;-]

Technical Details:
The vulnerability exists within the GIF parser in "ateimg32.dll". Below
are the details regarding this flaw:


The vulnerable exists within the GIF parser. You can see at the address
12081BDB, they set ebx with an argument supplied in the last argument:

..text:12081BDB mov ebx, [esp+arg_C]
..text:12081BDF test ebx, ebx
..text:12081BE1 jbe short loc_12081C1A
..text:12081BE3 mov ecx, [esp+arg_8]
..text:12081BE7 push esi
..text:12081BE8 push edi
..text:12081BE9 mov edi, [esp+8+arg_4]

Here is what the function declaration would look like:

unk_func(

struct aim_1 *arg_0,

struct aim *arg_4,

char *dest_buff,

int obj_cnt)

{

The last argument is a count. This routine appears to copy each entry
out until is done. Each iteration fo the loop obj_cnt is subtracted by
one. At 12081C13 you can see the dec ebx:

..text:12081C13 dec ebx
..text:12081C14 mov ecx, esi
..text:12081C16 jnz short loc_12081BED
..text:12081C18 pop edi
..text:12081C19 pop esi

This is basiclly a obj_cnt--; then you see the jnz. This means that the
counter isnt zero, then it jumps back up and does it again. Which would
kind of look like this:

while(1)

{

....

memcpy(...);

....

obj_cnt--; //decrement counter

if(!obj_cnt) //equal to zero

break; //leave loop

}


Now if the obj_cnt argument is zero, is when we have the problem. When
you subtract 1 from 0 you get -1. ;-] So, if im correct -1 is really
0xFFFFFFFF. So it only can can set 0-1=0xFFFFFFFF chunk, where per chunk
is only 30 bytes. ;-(

If you want to crash a remote host which is running the AIM client, use
the following .gif file as your buddy icon in Trillian and message a
friend which is using the AIM client:

http://security-protocols.com/poc/aim-DoS-.gif
or
http://fux0r.phathookups.com/aim-DoS.gif

Or, you can reproduce this problem just by using this buddy icon in AIM
locally.

Protection:
Dont use AIM~!

Vendor Status:
Im sure they will be releasing a patch very shortly.

Credit:
Discovery: Tom Ferris

Related Links:
www.security-protocols.com
www.eeye.com

Greetings:
chico the dog, connie, acidjazz, NiN, ,hugo the puto, jim beam, mike p,
flashsky, regulate, 011ie, mike in .mx, riley, modify, dmuz (call it a
truce?), ae, marc, and the rest of the eEye family.

Copyright (c) 2005 Security-Protocols.com

--
Tom Ferris
Researcher
www.security-protocols.com
Key fingerprint = 0DFA 6275 BA05 0380 DD91 34AD C909 A338 D1AF 5D78

Manu Benoît
08/06/05, 00:15
> .text:12081BDB mov ebx, [esp+arg_C]
> .text:12081BDF test ebx, ebx
> .text:12081BE1 jbe short loc_12081C1A
> .text:12081C13 dec ebx
> .text:12081C14 mov ecx, esi
> .text:12081C16 jnz short loc_12081BED
> .text:12081C18 pop edi
> .text:12081C19 pop esi

Unless I'm mistaken, the second line sets the Zero Flag if ebx (the argument)
is null then jumps after the end of the loop if the flag is set.

Which means that the count gets checked before entering the loop, and there
shouldn't be any problem.


--
TSeeker <tseeker@nocternity.net>