Tom Ferris
2005-06-07 07:38:21 UTC
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:
Loading Image...
or
Loading Image...
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
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
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:
Loading Image...
or
Loading Image...
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
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/