About libpurple's g_markup_escape_text() bug
elb at psg.com
Sat Oct 1 14:26:54 EDT 2011
(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
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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 482 bytes
Desc: Digital signature
More information about the security