Pidgin MSN memory corruption issue

[Paul Aurich]

So, is this just effectively a NULL pointer dereference or is there the
possibility for remote code execution?

(and Warren is pushing for a release soon)
~Paul

And Elliott Sales de Andrade spoke on 01/21/2010 07:23 PM, saying:
> Alright,
>
> 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).
>
>     ~P
>
>     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>
>     http://pidgin.im/cgi-bin/mailman/listinfo/security
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/cgi-bin/mailman/private/security/attachments/20100125/fd364f40/attachment.htm>
-------------- 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/security/attachments/20100125/fd364f40/attachment.pgp>