Re: AIM & @stake's advisory

[Packet of Sweets <definitely () ANTISOCIAL COM>]

> Hi all --
>
>       Nine months ago in March, 2000, I 
discovered the same vulnerability in AOL
> Instant Messenger (back then the latest version 
was 3.5.18??).  It was a
> buffer overflow in AIM's "screenname=" 
command line argument that is passed
> in via the "aim://" protocol of a browser.  I 
notified AOL, then posted to
> both BUGTRAQ and VULN-DEV.  My topic was 
approved in both forums soon
> after, but my thread gained little attention.  In 
addition, AOL simply
> ignored me.
>
>       I didn't do anything about it for two 
reasons.  First, my school workload
> was too great at the time to worry about 
anything else, and second, I
> figured that between all the people on the lists, 
if my topic was
> significant, something would get done.  Since it 
was basically ignored, I
> concluded that I was just a newbie and I set off 
everyone's "newbie
> o'meter" with my post.  Then summer hit, and 
well, you know....
>       And to top it off, a week or two ago I 
signed onto AIM for the first time
> in months and remembered all this.  I made a 
note to myself to investigate
> again on a boring day.  I guess can cross that 
off my to-do list!
>       - Joe Testa

 No kidding Joe. Here it is, almost the exact same 
(exploit code include -- no links to websites to 
view it either, did they Greetz you backz :-/)

To: Vuln-Dev 
Subject: Buffer overflow in AIM 3.5.1856 
Date: Sun Mar 19 2000 10:58:42 
Author: Joe Testa < jst3290 () ritvax isc rit edu > 
Message-ID: <38D52362.D0B1AEF2 () rit edu> 



[ Overview ]

A buffer overflow vulnerability has been found to 
exist in the lastest
build (3.5.1856) of AOL Instant Messanger (and 
possibly in older
versions too).  In problem arises out of the fact 
that proper bounds
checking is not performed on the command line 
arguements given to AIM.
This does not seem to be a particularly lethal bug 
until you consider
that AIM adds its own "aim:" protocol to Internet 
Explorer and
Netscape Navigator.


[ Details ]

AOL Instant Messanger build 3.5.1856 (March 
1st, 2000) blindly accepts
arguements passed to it, without caring to check 
its buffers for
proper space.  I have not the time to write an 
exploit to
demonstrate the existance of this bug beyond a 
reasonable doubt; ascii
values of arguement characters are added to 
0x20 first, then leak into
EBP and EIP.  So, this *appears* to be 
exploitable, and I invite anyone
out there with spare time to make an attempt.


To see a quick (and harmless) example, click <a
href="aim:goim?
screenname=AAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAA&message=EIP,+the+other+white+meat"
> here</a><br>.

Any data passed to AIM in a link by means of 
the 'screenname=' field
past the 244th character begins to overwrite EIP.


[ Solution ]

I do not know of any way to fix this problem 
besides installing the
proper patch when it arrives.  Trying to disable 
to 'aim:' protocol by
removing the following registry keys/values:

  HKEY_CLASSES_ROOT\aim\(Default)
  HKEY_CLASSES_ROOT\aim\URL Protocol
  HKEY_CLASSES_ROOT\AIM.Protocol
  HKEY_CLASSES_ROOT\AIM.Protocol.1

... does not work because AIM will restore the 
keys and values upon
next execution.  Renaming 'aim.exe' does not 
work, nor does renaming
AIM's directory.  On top of that, just plain 
watching your status bar
before clicking each link doesn't work either, 
because a malicious
attacker could mask the suspicious link URL with 
elementary JavaScript
skills....

Any help with a temporary solution is greatly 
appreciated.


[ Vendor Status ]

America Online was notified a week and a half 
ago, but has not yet
patched
their software.


----------------------


Greets to @Stake/L0pht and the cDc.

- Joe Testa (jst3290 () cs rit edu)