[8889] in bugtraq

home help back first fref pref prev next nref lref last post

Win32 ICQ 98a flaw

daemon@ATHENA.MIT.EDU (Justin Clift)
Fri Jan 1 15:58:51 1999

Date: 	Fri, 1 Jan 1999 14:20:34 +1100
Reply-To: Justin Clift <vapour@DIGITALDISTRIBUTION.COM>
From: Justin Clift <vapour@DIGITALDISTRIBUTION.COM>
To: BUGTRAQ@NETSPACE.ORG

Hello everyone,

A while ago I found a flaw in ICQ which I believe to be fairly serious and
asked whom to notify.  Thanks for everyone's assistance in this.  :-)

I notified Mirabilis and they have totally failed to respond (I've waited
about 2 weeks), so I'll now submit it here.

It's a very simple flaw.  At present I've only tested on the Win32 ICQ 98a
1.30 version, and have not tested on ICQ99 nor on other platforms.

Here is how it works : When a person is sending a file to another user on
ICQ, the person receiving the file has a window pop up which shows the
filename, a description entered by the sender, and options of where to save
or not save etc.

I've found there isn't a check on the length of the filename being sent.
The pane in the pop-up window will display as much of the filename as it
can, and if the filename is longer that the pane, the ending remainder won't
be displayed.

Therefore a simple attack is possible, sending a file named (for example) :

"leah2.jpg
.exe"

will display leah2.jpg to the receiving user whom will only see "leah2.jpg"
in the pop-up window and assume it is a harmless picture file for example,
not executable code.

This is very bad considering ICQ has the option of 'OPEN'ing the file once
the transfer is completed.  Many people do this to have the picture
displayed to them (by the program associated with the extension).  In the
case of this exploit, the executable code will be run instead of the program
the victim is expecting.  A craftily coded program would be able to do both
so as to avoid suspicion on the part of the victim.

One thing I have noted in testing is that on one person's system running
Win95 this did not work.  His computer renamed the file to .zip on receiving
which stopped the file executing.  I don't know why and as far as I have
been able to find out (I haven't had physical access to his PC) this is due
to his personal configuration and is not the norm.

One additional thing should considered also, and I don't yet have the time
and ability to do so; is a buffer overflow exploit present here or in other
versions which allows remote automatic code execution?  This depends on the
program and the protocol, of course.  It could be *very* bad.

Regards and best wishes,

+ Justin Clift
Digital Distribution
www.digitaldistribution.com

home help back first fref pref prev next nref lref last post