Pidgin MSN memory corruption issue

[Elliott Sales de Andrade]

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> 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>
> > Date: January 17, 2010 11:06:42 PST
> > To: Paul Aurich <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
> 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/20100121/2be9606b/attachment.htm>
-------------- next part --------------
#
# old_revision [7635af82fd23cb8baaab2cab5a8cbeb76f3ea5be]
#
# patch "libpurple/protocols/msn/slp.c"
#  from [3791d1f2ebc50ec51989809ba3548a65f9cacc84]
#    to [d033671387f0b1b7be03a6b2d9ab0df77f87096c]
#
============================================================
--- libpurple/protocols/msn/slp.c	3791d1f2ebc50ec51989809ba3548a65f9cacc84
+++ libpurple/protocols/msn/slp.c	d033671387f0b1b7be03a6b2d9ab0df77f87096c
@@ -741,11 +741,10 @@ msn_slp_sip_recv(MsnSlpLink *slplink, co
 	if (!strncmp(body, "INVITE", strlen("INVITE")))
 	{
 		char *branch;
+		char *call_id;
 		char *content;
 		char *content_type;
 
-		slpcall = msn_slpcall_new(slplink);
-
 		/* From: <msnmsgr:buddy at hotmail.com> */
 #if 0
 		slpcall->remote_user = get_token(body, "From: <msnmsgr:", ">\r\n");
@@ -753,7 +752,7 @@ msn_slp_sip_recv(MsnSlpLink *slplink, co
 
 		branch = get_token(body, ";branch={", "}");
 
-		slpcall->id = get_token(body, "Call-ID: {", "}");
+		call_id = get_token(body, "Call-ID: {", "}");
 
 #if 0
 		long content_len = -1;
@@ -767,13 +766,15 @@ msn_slp_sip_recv(MsnSlpLink *slplink, co
 
 		content = get_token(body, "\r\n\r\n", NULL);
 
-		if (branch && content_type && content)
+		if (branch && call_id && content_type && content)
 		{
+			slpcall = msn_slpcall_new(slplink);
+			slpcall->id = call_id;
 			got_invite(slpcall, branch, content_type, content);
 		}
 		else
 		{
-			msn_slpcall_destroy(slpcall);
+			g_free(call_id);
 			slpcall = NULL;
 		}