Inadvertent public disclosure of remote crasher

[Ethan Blanton]

Jan Lieskovsky spake unto us the following wisdom:
> >There has been a public disclosure, along with enough information to
> >reproduce, of a remote crasher in our SILC plugin:
> >
> >     http://developer.pidgin.im/ticket/14636
> 
> The reporter in that ticket mentions there might be more occurrences
> of the same deficiency in the Pidgin code. Quoting him, to be exact:
> 
> "I'm not sure if this is bug is only found inside the SILC plugin, I
> did not check other protocols, but anything using
> g_markup_escape_text() without making sure it is proper UTF-8 is
> potentially susceptible to the same problems."

No, I have not audited the rest of the code, I wanted to get this
patch out ASAP.  I personally do not have time to do a complete audit
in any event.

Note that this bug is in a protocol plugin.  Protocol plugins are, by
design, the only part of a libpurple client which is allowed to deal
with strings which are not valid UTF-8.  The bug here, in fact, is not
simply that a potentially invalid string is being passed to
g_markup_escape_text(), but that a potentially invalid string was
being passed through to libpurple.

> Simple grep of the code returns:
> 
> pidgin-2.10.0]# grep -rHn "g_markup_escape_text" * | wc -l
> 241
> 
> Wondering if you had chance to look / investigate also other places /
> occurrences of the same function call yet? If not, is there a plan
> to do so?

There are 134 occurrences of g_markup_escape_text in protocol plugins.
Occurrences of this function in libpurple, Pidgin, or finch do not
require validation, because there is no invalid UTF-8 present by
contract.  (Which is not to say that validation should never be
performed; however, salvaging and such are certainly not necessary.)
However, if an audit is performed, it should really be for validation
of incoming data in the general sense, not for this particular
function.  There are _many_ functions within libpurple which expect
valid UTF-8, and are likely to fail in undesirable ways if presented
with invalid strings.

As an example, all text which comes into the IRC protocol plugin
passes through irc_parse_msg().  This function validates or converts
almost all of the text which passes through it, but a manual
inspection reveals a couple of places where a malicious IRC server (I
don't see any client-provided unchecked fields) could inject invalid
UTF-8 which may make it past irc_parse_msg().  I don't know that any
of these injections could make it all the way to libpurple, or the UI,
but I will certainly be looking into that and ensuring that they
cannot.

It would be great to undertake this effort for all of our protocol
plugins.  It is a large job with a large surface area.  We have, in
the past, isolated such bugs in several protocols and fixed them.  I
am not sure we have ever done a complete audit.  If we have, it has
been a long time, and the code would benefit from another look.

> >As this bug was publicly disclosed before the fix was available, there
> >is no embargo.  We will be requesting a CVE as soon as we gather the
> >appropriate information from the discoverer.
> 
> Since the issue being public already, we can't assign a CVE identifier
> (since we would risk CVE duplicate. Maybe you aware of the policy
> already though). In any case, once the required information retrieved,
> would it be possible you to request the CVE identifier via the
> oss-security mailing list channel:? [1]
> http://oss-security.openwall.org/wiki/mailing-lists/oss-security

Yes, I understand that you cannot issue a CVE.  I will request via
oss-security.

Ethan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: Digital signature
URL: <http://pidgin.im/cgi-bin/mailman/private/packagers/attachments/20110930/187224ef/attachment.pgp>