bugtraq - AOL AIM Instant Messenger Buddy Icon "ateimg32.dll" DoS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <42A5D0B7.3090809@security-protocols.com>
Date: Tue, 07 Jun 2005 09:52:07 -0700
From: Tom Ferris <tommy@...urity-protocols.com>
To: bugtraq@...urityfocus.com
Subject: AOL AIM Instant Messenger Buddy Icon "ateimg32.dll" DoS

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