Pidgin 2.10.1

[Mark Doliner]

SUMMARY

There are three security problems for which we should release 2.10.1.
We have patches for the XMPP and oscar bugs, I just need to request
CVEs for them.  The SILC bug is half-fixed.  I have a patch that fixes
the other half... but I think it's likely that our SILC prpl is
riddled with crashes from failure to validate incoming text as UTF-8
(see the last paragraph of this email for more discussion).



BORING DETAILS

1. THE BUG: Remote crash in XMPP handling incoming malformed jingle
stanzas.  Discovered by Thijs Alkemade.  Not yet public (yay).  I'll
request a CVE from our packagers mailing list.

THE FIX: Not yet committed.  Paul Aurich sent out a first version of a
patch for this.  I made some small tweaks and fixed some mem leaks and
sent out a revised patch.  I think the new patch is pretty solid and
I'm happy with it.

2. THE BUG: Remote crash in oscar when handling incoming buddy
list-related SNACs.  Discovered by Evgeny Boger
(http://developer.pidgin.im/ticket/14682).  Already public.  I'll
request a CVE from the oss-security at lists.openwall.com mailing list.

THE FIX: Not yet committed.  I wrote the buggy code in question so I'm
pretty familiar with it.  I wrote a patch for this and sent it out on
November 6th.  I think the patch is pretty solid and I'm happy with
it.

3. THE BUG: Remote crash in SILC when handling incoming messages.
Already public.  Discovered by Diego Bauche Madero
from IOActive (http://developer.pidgin.im/ticket/14636).    Ethan
obtained CVE-2011-3594.

THE FIX: Partially committed.  Ethan committed
http://developer.pidgin.im/viewmtn/revision/info/7eb1f6d56cc58bbb5b56b7df53955d36b9b419b8
and that fixes one of the two functions (silc_private_message)
mentioned by Diego.  I have a local patch to fix the other function
(silc_channel_message).  It's exactly the same as Ethan's change...
just in a different place.  More importantly, I think it's very likely
that this same bug (failure to validate incoming text as UTF-8) exists
in many other places in the SILC code.  I think Ethan has said the
same thing.  One problem is that the original SILC dev (Pekka
Riikonen) doesn't seem to be around anymore.  It's not clear to me
where the UTF-8 validation should happen.  It seems like it would be
better if this was done by libsilc, but maybe that's not possible due
to how the API is structured?  I don't know.

So there's an open question of how we want to deal with future SILC
remote-crashers.  I'm inclined to not go through our standard
disclosure process for them, because I don't think enough people use
the SILC protocol to justify the work involved.  But I really have no
idea how many people use SILC.  We also may want to consider removing
the SILC PRPL.  I believe Debian no longer ships prpl-silc, and has
removed libsilc from their distribution because it's "orphaned"
(http://bugs.debian.org/638608  http://bugs.debian.org/629222
http://bugs.debian.org/629226).