Fwd: Re: Pidgin MSN memory corruption issue

Paul Aurich paul at darkrain42.org
Mon Jan 25 17:14:50 EST 2010

At Warren's request (and because Josh Bressers had a question about it
that I don't feel qualified to answer) here are some details on the
other MSN issue discussed in Fabian Yamaguchi's talk at 26C3.  Please
note that the details of this vulnerability are not yet public, nor is
this necessarily the final version of the patch.


-------- Original Message --------
Subject: 	Re: Pidgin MSN memory corruption issue
Date: 	Thu, 21 Jan 2010 22:23:09 -0500
From: 	Elliott Sales de Andrade <qulogic at pidgin.im>
To: 	Paul Aurich <paul at darkrain42.org>
CC: 	security at pidgin.im


I managed to take a look at this again today, and I think I tracked it
down. The patch is attached if you'd like to review it.

Stu and I were unable to reproduce the bug with the supplied PoC. We
determined that it's because of the hole plugged by the previous CVE.
However, after looking over the packet dump, I was able to figure out
how to reproduce it again (and without the victim's intervention).

The bug is related to the fix for CVE-2009-3083
<http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3083>. I find it
odd that it hasn't come up earlier, since the buggy client in that case
should have also triggered this one. The Java library used in the PoC
sends an invalid SLP invite (branch<space>{GUID} instead of branch={GUID}).

The problem arises in msn_slplink_process_msg, which contains pointers
to a slplink and to a slpmsg. Around line 623, it calls
msn_slp_process_msg, which then calls msn_slp_sip_recv. In this
function, a slpcall is created (which holds a pointer to the slplink).
Some elements are parsed, and checked for validity. Because of the
incorrect request by the PoC, the slpcall is destroyed and NULL is returned.

Given certain conditions, that could be a *bad* thing. The slpcall is
linked to a switchboard and the switchboard to the original slplink. If
the switchboard determines it's not in use (i.e., there's no normal
conversation occurring over it as well), then it closes and destroys
itself. The switchboard destroys all connected slplinks at that time,
including the original one. So then when msn_slplink_process_msg tries
to work with the slplink or the slpmsg, it's invalid.

The patch I included changes the order in msn_slp_sip_recv a bit. First,
all elements are parsed then verified. Only if everything exists is the
slpcall created. That means there's no extra allocation and no
accidental destruction of the original slplink in the case of invalid input.

On Sun, Jan 17, 2010 at 2:14 PM, Paul Aurich <paul at darkrain42.org
<mailto:paul at darkrain42.org>> wrote:

    I haven't looked at any of this yet (but I am confirming with him
    that there's no embargo date).


    Begin forwarded message:
    > From: Fabian Yamaguchi <fabs at recurity-labs.com
    <mailto:fabs at recurity-labs.com>>
    > Date: January 17, 2010 11:06:42 PST
    > To: Paul Aurich <darkrain42 at pidgin.im <mailto:darkrain42 at pidgin.im>>
    > Subject: Re: Pidgin MSN memory corruption issue
    > Hey Paul,
    > I've assembled some information for you to reproduce the issue. The
    > attached tarball includes a proof of concept exploit, two packet-logs,
    > one from the attacker to the server and another from the server to the
    > attacked host, and a backtrace obtained from gdb.
    > To run the code, you'll need the newest SVN-snapshot of the java MSN
    > Library, which you can find at: http://jml.blathersource.org/.
    > Hope this helps you guys fix the issue.
    > Fabian


    security mailing list
    security at pidgin.im <mailto:security at pidgin.im>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/cgi-bin/mailman/private/packagers/attachments/20100125/e2764984/attachment.htm>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pidgin-CVE-2010-0277.diff
URL: <http://pidgin.im/cgi-bin/mailman/private/packagers/attachments/20100125/e2764984/attachment.asc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://pidgin.im/cgi-bin/mailman/private/packagers/attachments/20100125/e2764984/attachment.pgp>

More information about the Packagers mailing list