Bug 62226 (CVE-2004-0891)

We received the following report via vendor-sec.
This issue is not public yet, please keep any information about it inside SUSE.
CRD is 2004-10-19

Date: Wed, 13 Oct 2004 13:37:55 -0400
From: Josh Bressers <bressers@redhat.com>
To: vendor-sec@lst.de
Cc: gaim-packagers@schierer.org
Subject: [vendor-sec] FWD: [gaim-packagers] Gaim 1.0.1 MSN security issues

Here's a new issue in the current Gaim MSN protocol parser.  Issue #3 below
has been given the CVE id CAN-2004-0891.

The current embargo date is 2004-10-19.


----- Forwarded message from Stu Tomlinson <stu@nosnilmot.com> -----

While investigating a crash in Gaim's MSN protocol I discovered 3
potential security issues.

1) Crash when accepting a large file transfer that exceeds the amount of
available memory.
Affected code: src/protocols/msn/slplink.c
After accepting a file transfer request, Gaim will attempt to allocate a
buffer of a size equal to the entire filesize, this allocation attempt
will cause Gaim to crash if the size exceeds the amount of available
memory.

Fix: don't allocate a buffer for file transfers, it's not necessary.

2) Crash when receiving malformed MSNSLP message
Affected code: src/protocols/msn/slplink.c
Gaim allocates a buffer for the payload of each message received based
on the size field in the header of the message. A malicious peer could
specify an invalid size that exceeds the amount of available memory.

Fix: Replace call to g_malloc() with call to g_try_malloc(). If the
memory could not be allocated the function returns instead of causing
the application to crash.

3) Buffer overflow when receiving unexpected sequence of MSNSLP messages
Affected code: src/protocols/msn/slplink.c
memcpy was used without checking the size of the buffer before copying
to it. Additionally, a logic flaw was causing the wrong buffer to be
used as the destination for the copy under certain circumstances.

Fix: Correct the logic to select the correct buffer, and add bounds
checking to prevent malformed messages causing a buffer overflow.


All 3 bugs affect MSN's MSNSLP protocol, which is peer-to-peer, so these
could potentially be easy to exploit. They have been present since Gaim
0.79

I have attached a patch against Gaim 1.0.1 which addresses these issues.

Regards,


Stu.



----- End forwarded message -----
_______________________________________________
Vendor Security mailing list
Vendor Security@lst.de
https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec