[5809] in bugtraq
Re: Vulnerabilities in ICQ
daemon@ATHENA.MIT.EDU (Solar Designer)
Tue Dec 16 14:38:23 1997
Date: Tue, 16 Dec 1997 20:20:41 -0300
Reply-To: Solar Designer <solar@FALSE.COM>
From: Solar Designer <solar@FALSE.COM>
X-To: smm@WPI.EDU
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <3.0.5.32.19971214211714.0085c3d0@pop.wpi.edu> from "Seth McGann"
at Dec 14, 97 09:17:14 pm
Hello,
> The Client-To-Client Protocol used by ICQ is even worse. It does no
> authentication of any kind and places all trust in the client. Spoofing
> messages from arbitrary ICQ users is easy, as is sending file and chat
> requests. Even worse, if the client gets anything it doesn't expect it
> crashes(!) sometimes taking Windows with it.
Spoofing chat requests? Crashes?
00422D4D lea ecx, [ebp-118h]
00422D53 push dword ptr [esi+18h]
00422D56 push offset aTheFollowingRe
00422D5B push ecx
00422D5C call ds:sprintf
...
004B58F8 aTheFollowingRe db 0Dh,0Ah ; DATA XREF: _text:00422D56o
004B58F8 db 'The following reason for a chat request was given: ',0Dh,0Ah
004B58F8 db ' %s',0Dh,0Ah,0
Unless there's bound checking done before we get here, this overflow is
exploitable -- the buffer is on the stack. I'm too lazy to boot Windows
to check now.
Anyway, there're 100+ references to sprintf() and strcpy() in ICQ, at least
some of these have to be exploitable. IDA (the disassembler) is even able to
detect standard MSVC functions, so you get symbolic names for them right
after the disassembly, and can open a window with the cross references list.
Signed,
Solar Designer
