[Fwd: Re: [Advisories] Libpurple security vulnerability CORE-2009-0727]
paul at darkrain42.org
Mon Aug 10 16:17:48 EDT 2009
-------- Original Message --------
Subject: Re: [Advisories] Libpurple security vulnerability CORE-2009-0727
Date: Mon, 10 Aug 2009 17:09:51 -0300
From: Core Security Advisories Team (jo)
<advisories-publication at coresecurity.com>
Organization: Core Security Technologies
To: Luke Schierer <lschiere at pidgin.im>, darkrain42 at pidgin.im
CC: Core Security Advisories Team (jo)
<advisories-publication at coresecurity.com>, Federico Muttis <acid at corest.com>
References: <4A6E328C.2090507 at coresecurity.com>
<3FB270B3-D400-4E91-8AC2-364B12ED268F at pidgin.im>
<4A6F56B4.10505 at coresecurity.com>
<3B877F37-FDF3-4820-B13B-9AB8D22FB6E9 at pidgin.im>
<4A70C622.7050906 at coresecurity.com>
<A40E1518-B0E9-4F6C-9F87-195E90F9E5C6 at pidgin.im>
<4A71D592.5090407 at coresecurity.com>
<DE0DB244-09F1-4F20-AC15-2F818134AB3C at pidgin.im>
<4A733A70.8060108 at coresecurity.com>
Hi Luke and Paul,
Do you have any update on the bug Federico found? Please send us any
version/patch information you have. Also we include in our advisories a
Vendor Section including workarounds and solutions. Please send us
content for that section if you want to include something.
Core Security Advisories Team (jo) escribió:
> 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.
> 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?
>> On Jul 30, 2009, at 13:17 EDT, Core Security Advisories Team (jo) wrote:
>>> 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.
>>> --José I. Orlicki
>>> Advisories Team
>>> Core Security Technologies
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 898 bytes
Desc: OpenPGP digital signature
More information about the Packagers