[Fwd: Re: [Advisories] Libpurple security vulnerability CORE-2009-0727]

[Paul Aurich]

I've attached a debug log of this crashing (with no relevant changes in MSN
from 8351342d3a30c75649de9c3d4abc7b6f45ce8f82, which is im.pidgin.pidgin
head at mtn.pidgin.im).

I'm not familiar with MSN, but is it pertinent that they're using the base
ID from the "reply of the first message":

        # Get the base id from the reply of the first message,..
        base_id = sb_msnms_object['p2p_binheader'][4:8]

It looks abnormal, and the slpmsg that's found during the processing of the
second message is the *ACK* to the first message (instead of the first
slpmsg created, which actually does have a buffer) -- it's not visible in
this debug log, but I verified in a second run.

Anyway, log attached
~Paul

And Luke Schierer spoke on 07/31/2009 12:22 PM, saying:
> ---------------------------- Original Message ----------------------------
> Subject: Re: [Advisories] Libpurple security vulnerability CORE-2009-0727
> From:    "Core Security Advisories Team (jo)"
> <advisories-publication at coresecurity.com>
> Date:    Fri, July 31, 2009 14:39
> To:      "Luke Schierer" <lschiere at pidgin.im>
> Cc:      "Federico Muttis" <acid at corest.com>
>          "CORE Security Technologies Advisories-publication"
> <advisories-publication at coresecurity.com>
> --------------------------------------------------------------------------
> 
> Luke,
> 
> Here is the PoC that triggers the bug. To run exploit.py you must first
> edit msnclient.py:
> 
>        # Setup some MSN accounts
>        self.account = "Attacker MSN account"
>        self.password = "Attacker password"
>        self.victim = "Victim MSN Account"
>        self.display_name = "My Display Name"
> 
>        # Set your proxy if you need it, with this format:
>        #self.proxy = "192.168.254.254:80"
>        # Else, leave it blank.
>        self.proxy = ""
> 
> Don't hesitate to write if you have any doubt or comment.
> 
> Regards,
> Jose.
> 
> Luke Schierer escribió:
>> We have looked into the code and we're not sure how this can be triggered.
>> You have outlined a two-step process. For the second step, you say
>> buffer is NULL, thus allowing a memcpy to an arbitrary location.
>> However, we don't see how this could happen. The buffer should either
>> have been allocated in the first step, or if that fails, the original
>> message would be destroyed. And without that, the second part could
>> not occur. So, how are you getting buffer to be NULL?
>>
>> Thanks!
>>
>> Luke
>>
>> On Jul 30, 2009, at 13:17 EDT, Core Security Advisories Team (jo) wrote:
>>
>>
>>> Hi,
>>> I am attaching a preliminary version of the advisory, written by
>>> Federico Muttis, encrypted with Luke's key. Don't hesitate to write back
>>> if you have any doubts or comments.  We are planning to release the
>>> advisory on August 18th, 2009.
>>> Regards,
>>> Jose.
>>> --José I. Orlicki
>>> Advisories Team
>>> Core Security Technologies
>>>
>> http://corelabs.coresecurity.com/index.php?module=FrontEndMod&action=list&type=advisory
>>
>>> <pidgin-1.txt.pgp>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: backtrace.log
Type: text/x-log
Size: 19282 bytes
Desc: not available
URL: <http://pidgin.im/cgi-bin/mailman/private/packagers/attachments/20090801/62b669ad/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 898 bytes
Desc: OpenPGP digital signature
URL: <http://pidgin.im/cgi-bin/mailman/private/packagers/attachments/20090801/62b669ad/attachment.pgp>