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@xxxxxxxxxxxxx) -------------------------------------------------------------------------------- References: 1. The EKG Documentation, http://dev.null.pl/ekg/docs/protocol.html, 09/10/05
