Message-ID: <438192A9.6090303@man.poznan.pl>
Date: Mon Nov 21 13:45:31 2005
From: sloik at man.poznan.pl (Jaroslaw Sajko)
Subject: Gadu-Gadu several vulnerabilities (version <=
	7.20)

21/11/05
Gadu-Gadu instant messenger several vulnerabilities


I. INTRODUCTION

During the preparation of the materials about instant messengers
security for the security conference we have checked current state of
the Gadu-Gadu (http://www.gadu-gadu.pl) security. There was discovered a
several new vulnerabilities. They are shown below.

II. VULNERABILITIES

-= Image sending =-

GG allows sending images between the users. The algorithim of this
mechanism is as follows:

1. Sender's messenger sends the signature of the image (length and
checksum).
2. The receiver's messenger checks for presence of the image in the
harddisk (according to the received signature). If it is on disk go to 6.
3. No image in the cache => get it from the sender
4. The sender's messenger sends the image itself as a binary stream with
the filename.
5. The receiver's application saves the image on the disk, go to 7.
6. Read the image file name from the cache
7. The image is displayed in the chat window (chat window is the HTML
page so the image is represented by the imgsrc tag with the reference to
the file on the user's disk).


vulnerability #1 (version <= 7.20):

Sender specifies the file name. The file name for example could be the
special device. If you name your image the 'LPT1:' you are going to
write the image content to the lpt1 port of the receiver. If you name
your image 'AUX:' and send it two times. The second time blocks the
thread which is responsible for displaying, receiving and sending of the
messages.


vulnerability #2 (version 7.20 an probably older 7 subversions):

For the last time (a year ago) we have checked the GG aplication there
was a stack based buffer overflow concerned with the length of the image
filename. This time there is similiar stack based buffer overflow. If
the image name length is between 192 and 200 (inclusive) the buffer is
overruned. Beacause the buffer has hard written length and it is the 200
bytes, file name is checked for that constraint but after that is
concatenated with the "imgcache\" string and copied to the buffer on the
stack. So the 9 bytes can be overwritten. Exploitation is - according to
our knowledge - very hard, beacause the application is stack guarded and
immediate after the buffer lies the canary value. But the DoS is possible.


-= Direct connections =-

The GG allows users to communicate via the VoIP, Video and alows them
for transfering files. This feature is built on the strength of the
direct connections. Again, this time there is also the proprietary
protocol which is stateless and packets are unnumbered. Some protcol
codes are accepted but has no functionality. These protocol codes are to
the ceratin point processed. This certain point is after the memory
allocation for the service purposes procedure. Eventually packet is
dropped but the memory is not released. The portion of code which
maintains direct connections is really very interesting area.


vulnerability #1 (version 7.20 an probably older 7 subversions):

Over the direct connection, initialized by CTCP packet (look at [1])
with the code 0x01 we can send the DCC packet (look at [1]) with any
code. If this code will be != 2 the next 4byte value which lies after
the DCC code in the packet will be treated as the content size. The
victim's application allocates such a memory if its size is < 0x10000.
And the packet is dropped, but we can send it again. And again, and
agaian, and eventually the memory will exhaust.


vulnerability #2 (version 7.20 an probably older 7 subversions):

The DCC packets with codes like 6 or 7 triggers window popups with error
messages (like "the user refuses to receive the file"), but in these
messages is no information which user is the source of that error and
also the overall context doesn't matter. So you can send, again and
again the error messages, without any prior other message exchange, and
the windows will be popping up. This is at least annoying but there is
another consequence. Each packet implies creation of the two new
threads, one for the packet processing and the second for the window
displaying. The first thread accomplishes when the user close the error
window. If the user is not fast enough or it is away from the computer
such a flooding can lead to the DoS.


-= GG Moniker =-

During the process of the installation the gg moniker is created. This
is the "gg:" URI handler. Using this handler the web page can invoke the
gg application.

vulnerability #1 (version 7.20 an probably older 7 subversions):

Puting many times the "gg:" reference on the page result withe the many
instances invoked. And after the creation of several instances the
application crashes and somtimes the configuration is lost (probably
beacause of inproper concurrent access). This can lead to the DoS.


-= GG phonecalls =-

One of the GG features allows users to making the regular phonecalls. GG
phone uses for the comunication the EasycallLite.oce ActiveXObject. This
object can be  created from the web page as well.

vulnerability #2 (version 7.20 an probably older 7 subversions):

It is possible to create the web page which will instatiate the
EasycallLite.oce object and will make the call to the given number.
Beacause the whole process goes behind the user such a page can be used
to eavesdrop the user (if he has the microphone of course).

III. PROOF-OF-CONCEPT

We're not going to release the proof-of-concept codes to the public.


IV. VENDOR RESPONSE

Few days ago the vendor has released new version of the Gadu-Gadu
application (version 7 build 21 and version 7 build 22), which is
probably corrected (The vendor has decided to not inform us about the
new release and the users about security vulnerabilities, so we don't
know if the vulnerabilities are properly fixed, but we've noticed the
new version is available on the Gadu-Gadu website).


Blazej Miga
Jaroslaw Sajko
PSNC Security Team (security@....poznan.pl)

--------------------------------------------------------------------------------
References:
1. The EKG Documentation, http://dev.null.pl/ekg/docs/protocol.html,
09/10/05

Powered by blists - more mailing lists