About libpurple's g_markup_escape_text() bug

[Diego Bauche Madero]

Hi Ethan,

I usually do not disclose such bugs in this manner. I just couldn't
find a way to report a security bug (And... I'm guessing that the
email address for security@ was somewhere inside the page, I was just
dumb enough not to find it... My apologies if I caused any trouble).
I'm not releasing a PoC in any case (Even though it's easy to trigger
anyway). I'll be careful to report such bugs to security@ next time.

Sure, you can use my Name and Email address for the CVE request.

Thanks.
--Diego


On Sat, Oct 1, 2011 at 1:26 PM, Ethan Blanton <elb at psg.com> wrote:
> (Cc:ing security at pidgin.im)
>
> Diego Bauche Madero spake unto us the following wisdom:
>> The bug is also present on silc_channel_message() with the UTF8 flag,
>> there's also other flags that also trigger the use of
>> g_markup_escape_text().
>
> I will look into this.
>
>> g_markup_escape_text() seems to be used quite a lot all around the
>> protocols (according to egrep). I'm sure there must be many other
>> parts of the libpurple protocols that have the same issue.
>
> Yes, it is, and we've been having a discussion about this since your
> bug report.  I have already audited the IRC protocol in this respect,
> but it is somewhat better structured than many of the other protocol
> plugins, and therefore easier to clean up.  In fact, it already had
> correct checks in place for all but a couple of overlooked messages
> which require a compromised server (or man-in-the-middle) to exploit.
> (I don't actually think any of them involved g_markup_escape_text, and
> most did not even make it out of the prpl, but better safe than
> sorry.)
>
> Note that there are actually two bugs here; one is the passing of
> unverified text to g_markup_escape_text(), and the other is the
> passing of unverified text into libpurple.  Libpurple's contract with
> its protocol plugins is that only valid UTF-8 text crosses the
> libpurple/prpl interface, and the SILC plugin was (potentially)
> violating this contract.
>
> I wanted you to contact me directly to discuss disclosure procedure.
> First off, I want to thank you for your careful and detailed bug
> report.  It is not often that we get bug reports of such high quality.
>
> Second, I would like to ask you for permission to use your real name
> (Diego Bauche Madero, I assume?) to request a CVE from the
> oss-security group.  We will post this CVE number along with a
> description of the vulnerability to our web site, as well as reference
> it in the 2.10.1 release.  This will help people track which libpurple
> versions are vulnerable.
>
> Finally, I wanted to mention that the manner of your submission of
> this bug report is somewhat problematic for us, and explain why, to
> help you and other open source projects in the future.  By submitting
> a bug report directly to the public tracker along with detailed
> instructions for how to trigger it, you created a zero-day exploit for
> libpurple-based clients.  Anyone with a keyboard can log into SILCnet
> and crash connected libpurple clients with essentially no effort, and
> there is no upgrade publicly available to mitigate this attack.
>
> I have already patched the libpurple sources for this particular
> exploit, and a patch has been made available to most major Linux
> distributions which package libpurple along with a link to your bug
> report and a request for immediate release of patched packages.  We
> will be releasing a 2.10.1 containing this patch on an accelerated
> schedule in order to get fixes out to people who build from source,
> Windows users, etc.
>
> In the general case, it is better and easier for all involved if
> security-related issues are reported directly to an open source
> project via a private contact.  In the case of Pidgin/libpurple, we
> have the security at pidgin.im mailing list, linked from our support page
> at http://pidgin.im/support/.  In other cases an email to a developer
> may be appropriate.  This allows the project to prepare a fix for the
> vulnerability, contact vendors, and perform a coordinated disclosure
> of the vulnerability in tandem with the release of source code which
> fixes it.  This closes the window for exploitation significantly, as
> patched packages can be released for most users at the same time as
> the vulnerability becomes known to the public at large.
>
> I see from your web page that you have done previous security-related
> work, and you may already be aware of these issues, but simply unaware
> that our tracker is as public as it is.  In that case, please
> understand that many open source projects have achieved a level of
> openness and transparency which makes any but private communication
> essentially impossible to embargo.  In the case of the pidgin.im bug
> tracker, when a bug is submitted its details are transmitted to a
> public mailing list which is archived in multiple locations, including
> some which we do not control.
>
> In summary, I would like to thank you again for your fantastic report,
> but ask you to contact us directly with future security-sensitive
> bugs.  I would also like your permission to use your real name and
> email address in a CVE request.  Additionally, I encourage you to
> continue to audit libpurple for security issues!  Dedicated security
> auditers are something which most Open Source projects do not have the
> luxury of, so it is the dedication of users like yourself which helps
> keep us safe.
>
> Ethan
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQEVAwUBTodbbv8fixZ3H8crAQisBAgAwCl3ZPpaFPUFLkQu0Cbr1AdjSLSPraJs
> 2+/1stgsbeR14wz3niZG/2JIzhosEtMk+qqMH1QnsJPEIa9+EfwsYD4SVEBTu4Wd
> J5MsSAWHZ2IaUIfPCoFGL/CC5eXzuEDwZXPFW6VeNAhWrrM1/FaRGxCoUp+fzCoy
> 2zjEuwmBZqdHLkN3gjyP61b+qOQg92qlyWNEPf5uXK9KP/hEMwdkeZ/qnp8w3y9J
> EM8mMd2YaSBydLuG4f17Hj9r2pRhK1GPC2/e1yRfyRw8eF4OGMYhGcE1yjwwDtQj
> WacNTzFHAzrzvIE+2gf2CN4xhJN6OjuuLBzegLCrqdCiypa2Vm2QZw==
> =J1yY
> -----END PGP SIGNATURE-----
>
>