Home    |    View Topics    |    Search    |    Contact Us    |   



Category:   Application (Instant Messaging/IRC/Chat)  >   AOL Instant Messenger Vendors:   America Online, Inc.
AOL Instant Messenger Temporary File Flaw May Allow Remote Users on an AIM Direct Connection to Create Files With Arbitrary File Names on the Host
SecurityTracker Alert ID:  1004081
SecurityTracker URL:
CVE Reference:   GENERIC-MAP-NOMATCH   (Links to External Site)
Date:  Apr 17 2002
Impact:   Execution of arbitrary code via network, Modification of system information, Modification of user information
Exploit Included:  Yes  
Version(s): 4.8 beta and prior versions
Description:   A temporary file naming vulnerability was reported in AOL Instant Messenger (AIM). A remote user with an AIM 'direct connection' to another user may be able to create nearly arbitrary files with fully arbitrary file names on the other user's computer.

It is reported that when a user sends an image or audio item to another AIM user via the AIM 'direct connection' function, the receiving AIM client specifies the original name and path of the file being sent as part of the "SRC" parameter. In addition, when the client recognizes a file that has a RIFF/WAVE MIME type, the AIM client will download the file to the Windows 'temp' directory and play that file as soon as it is downloaded via the 'SndPlaySoundEx' API function. Apparently, the client will use the original filename from the "SRC" parameter as the temporary file name. As a result, the AIM server (the peer that is sending the file) can specify a file name that includes directory traversal characters ('../') to cause the file to be saved anywhere on the AIM client host.

It is also reported that the AIM client only analyzes the first 12 bytes of the file to determine if the file is really a sound file. Because of this, it is apparently not possible to directly create executable files with this exploit method. However, scripts can be created.

Some demonstration exploit examples are provided in the Source Message.

Impact:   A remote user can create files with certain contents and with arbitrary file names on the target user's computer. This could be used to overwrite files on the target user's computer or to save scripts (batch files) on the target user's computer.
Solution:   No solution was available at the time of this entry.
Vendor URL: (Links to External Site)
Cause:   Access control error, State error
Underlying OS:  Windows (Any)

Message History:   None.

 Source Message Contents

Subject:  AIM's 'Direct Connection' feature could lead to arbitrary file

AIM's 'Direct Connection' feature could lead to 
arbitrary file creation
Author: Noah Johnson ( )

Affected versions: 
         All versions of AOL Instant Messenger (up to 
4.8 beta) on all platforms of Windows (as far as I can 

        AOL may have patched their servers to prevent 
the wave of DoS attacks recently discovered, but this 
bug - related to the 'Direct Connection' feature - 
cannot be filtered through the server itself, and 
therefore requires a new realease to be patched. 
        Because direct connections (almost always) 
require user approval, the severity of this bug is 
somewhat smaller than others recently discovered, 
however exploitation is fairly simple and could result 
in anywhere from arbitrary script execution to 
overwriting of critical files, and so I think it's still 
worthy of being noted and fixed soon.

          The problem arises in AIM's handling of 
embedded objects during direct connections with 
other users. These 'direct connections' supposedly 
make it easier for users to share multimedia with 
each other during conversations. When a direct 
connection is to be made, the initiating side acts as a 
server - on port 4443 - for the recipient's client to 
connect to (if the request is accepted, of course). 
After this connection is made, all activity between the 
two users is passed through it, relieving the AIM 
server of its job for the time being.
         When a user sends a picture or a sound to his 
buddy, an <IMG> tag is appropriately inserted into the 
conversation source, while that file's data lies in a 
separate <DATA> tag immediately proceeding the 
HTML (see below). The client responds to this <IMG> 
tag either by displaying the picture in the conversation 
or by displaying an icon of the MIME/file-type that has 
been sent. Along with the standard parameters of this 
<IMG> tag (HEIGHT, WIDTH, DATASIZE, ID, etc...), 
the client also specifies the name and path of the 
original file that was sent. This information is included 
in the "SRC" parameter, and is the one of importance 
here. The client uses this information in a few ways - 
including the default filename suggested when the 
user opts to save whatever the hell was sent.
So, why does anyone care?
       One last nifty feature I forgot to mention... When 
the client parses the file and recognizes it as a 
RIFF/WAVE type, it will play that file instantly via 
the 'SndPlaySoundEx' API function. Instead of playing 
the buffer directly from memory however, it is instead 
downloaded into the Windows 'temp' directory and 
read from there. But for some odd reason, THE 
TEMPORARY FILE! (Can you see where this is 
        With very trivial parsing of this "SRC" parameter, 
AIM is left wide open to the old ("..\..") directory 
traversal attack. So now we can choose ANY path on 
our buddy's system to save our file to simply by 
appropriately sculpting the "SRC" information. Here's 
an example of what might be sent from the direct 

Data Headers (explained later)
<HTML><BODY>Hey, what's up?<IMG 
SRC="\..\system\johnny.important_file" HEIGHT="0" 

       Assuming that the temp directory on Johnny's 
computer is [c:\windows\temp], this would 
write/overwrite whatever file was thus specified. No 
obvious signs of this would be noted, as the WAVE 
icon would never show up in Johnny's box (notice the 
HEIGHT and WIDTH values).

Fooling the Client:
        As noted earlier, AIM only saves this (semi-)
temporary file when it identifies it as valid RIFF/WAVE 
data and tries to play it. So what good is this if we can 
only write WAVE files? ("HOLY SHIT! YOU MEAN 
Unfortunately for Johnny, the client only looks at the 
first 12 bytes before concluding it is indeed a valid 
sound file. These bytes ideally look like this (see 
wave file specifications):

Offset      Data
0,1,2,3	ASCII 'RIFF'
4,5,6,7     DWORD Wave File Size ( <- can be 
anything, we don't care; 		
	neither does the client. )

      Keeeping this as a base, we can then sculpt any 
file we want (sample exploits next). As long as these 
12 bytes are respected (actually, only the ASCII parts 
of them really matter), the file is saved. 
      The fact that the header is already determined 
severely limits the danger of this bug (we cannot, for 
example, create an executable file). There are a few 
ways around this...

       Besides the potential of overwriting files, there 
are plenty of file types that can be bullshitted in the 
first 12 bytes without losing functionality of the entire 
thing (think scripts, for example). By placing these 
files in the Start-Up folder, you can see where this 
could lead...

For example:
	A sample .BAT file
	C:\Windows\Start Menu\StartUp\exploit.bat 
	Any dos command here
	Any dos command here
	While I originally assumed the '-'s would be 
the ASCII character 0x08 (backspace, which would 
delete the 'WAVE' and 'RIFF' so the shell would not 
try to execute these commands, give an error and 
then quit), it turns out that even if an error is 
encountered ('Invalid command or file name'), it will 
not stop the rest of the script from executing upon 

Another example:
	A sample .VBS file
	C:\Windows\Start Menu\StartUp\exploit.vbs
	RIFF____WAVE = ""
	Any vbs code here
	Any vbs code here
	Here, the first line (RIFF____WAVE = "") is 
a valid declaration, which means no error will occur in 
scripting and anything else can be put in afterwards.

... You get the idea. I'm sure there are plenty of other 

      It's just like they tell you... Never accept a direct 
connection from anyone you don't trust. If you MUST, 
I suppose you could change your Windows temp 
directory to thwart a maliciously located file, but I 
would hardly consider that a 'fix'.

A Few Things to Note:
      Because AIM only allows multimedia to be sent in 
Direct Connection sessions (not quite true, see note 
on Buddy Icons), and because AIM filters out HTML 
tags (such as our <IMG> tag here) when inserted 
directly into an IM message, in order to exploit this 
bug a user must be able to control the raw data being 
sent. The most obvious way is to simply take control 
of the port that the connection is to be made on 
(before the client does) and sculpt the data on your 
       But sequence numbers are used in the 
transmission of data during these sessions. The 
base sequence number is randomly selected by the 
initiating side, and is sent to the buddy's client as part 
of the request for a connection (Port # is sent at the 
same time). This sequence is incremented every 
time an entire chunk of data is sent (which could 
span any number of packets; the size of every data 
piece is sent right after the sequence number). If the 
sequence number or data size is wrong, the direct 
connection will be closed immediately. You can 
experiment on your own on port 4443.

     The simplest way I can think of to test this bug 
(avoiding dealing with sequences and protocols) is to 
let the client handle everything - the connections and 
all - and manually edit the conversation source [with 
the 'wave file' already inserted] just before it's sent 
out (SendWindowMessage (WM_SETTEXT) on the 
RichTextBox or use SoftIce and search for the data in 
memory or something to that nature). I won't publish 
a full-out exploit; I think you get the picture.

* A Note on Buddy Icons *
       If you send this same type of forged WAVE file 
as a Buddy Icon (no direct connection needed), the 
client does the same thing described earlier, even 
before the "Accept Buddy Icon" prompt appears. I 
don't know if this is intentional on the part of AOL, but 
as far as I can tell it's impossible to specify your own 
file name. Instead the client uses some default name 
of its own. It's just odd, because I was under the 
impression that Buddy Icons were supposed to be 
graphic files >>> (Possible DoS in this - send a 
corrupt wave file to buddy's computer? I don't know, 
anyone care to investigate?)
      Also, when a buddy is sent your Buddy Icon, the 
file is downloaded onto their computer and saved 
Located in their AIM user's 'picture' folder and 
named '', THEORETICALLY one could use this 
place to store an executable file to be renamed and 
executed later via script. Just a thought, but you didn't 
hear that from me...



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