Upcoming Pidgin security disclosures and 2.10.1

[Mark Doliner]

On Thu, Dec 8, 2011 at 4:08 AM, Jan Lieskovsky <jlieskov at redhat.com> wrote:
> On 12/06/2011 10:57 AM, Mark Doliner wrote:
>> 1. Remote crash in XMPP handling incoming malformed jingle stanzas.
>> This issue is not yet public.  Thijs Alkemade discovered it and
>> notified us privately on October 23.  Josh, Jan, and Tomas of Red Hat:
>> Would one of you be able to issue a CVE for this issue?  A patch can
>> be downloaded from
>> http://www.pidgin.im/~markdoliner/3fK87mgWR53g45p/fix_jabber_crash.diff
>
> From what I can tell after looking at the patch, it's fixing multiple
> NULL pointer deference flaws, right?

Correct.

> The point of adding purple_strequal() routine:
> [1] http://developer.pidgin.im/ticket/7790
> seems to be to have available a routine, which would duplicate content
> of one argument to the other without crashing when receiving NULL pointer
> / value, right?

purple_strequal() COMPARES rather than DUPLICATES, but yes, basically correct.

> And by you referenced patch above, seems to ensure, that we wouldn't crash
> when there are NULL values provided in various fields of Jabber Jingle
> stanza, right?

Correct.

> Thus this shouldn't be exploitable for anything more than just pidgin
> crash via specially-crafted Jingle stanza, right?

Correct.

> Also, to fix these issues in older (v2.6) Pidgin versions, it wouldn't
> be sufficient to apply the above proposed patch, but also to apply
> the commit introducing the purple_strequal() routine, right?
> (if this got introduced later than in v2.6 version)

The crash only affects Jingle code, which I believe was added in
2.6.0.  I don't know why purple_strequal() was added.  But yes, if
purple_strequal() didn't exist in 2.6.0 then you would need to also
apply the commit introducing purple_strequal().

>> 2. Remote crash in oscar when handling incoming buddy list-related
>> SNACs.
*snip*
>> http://www.pidgin.im/~markdoliner/3fK87mgWR53g45p/fix_oscar_crash.diff
>
> From look at the patch it implies, this is similar issue (IOW heap based
> buffer overflow) like CVE-2011-3594 was. Just not in SILC plug-in this
> time, but rather in Oscar protocol plug-in.

Correct.