Upcoming Pidgin security disclosures and 2.10.1

[Jan Lieskovsky]

Hello Mark,

   thank you for your reply and confirmation / corrections.

Three points yet.

On 12/08/2011 11:22 PM, Mark Doliner wrote:
> 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().

1) Thank you. This is clear now and pending CVE assignment (will potentially
assign both of them at once. Please see below).

2) Have Cc-ed my team-mate Huzaifa Sidhpurwala on this post, as he is working
on this task in Red Hat and should be aware of conclusions / able to comment.
He is being aware of the policy, how to deal with this kind of issues, so
no worries.

>
>>> 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.

Thank you for the confirmation.

3) Will return to the CVE-2011-3594 issue yet.
a, https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2011-3594
    (Red Hat Bugzilla bug)
b, 
http://developer.pidgin.im/viewmtn/revision/diff/be5e66abad2af29604bc794cc4c6600ab12751f3/with/7eb1f6d56cc58bbb5b56b7df53955d36b9b419b8
    (originally proposed upstream patch)
c, http://www.pidgin.im/~markdoliner/3fK87mgWR53g45p/fix_silc_crash_CVE-2011-3594.diff
    (the new CVE-2011-3594 patch version you mentioned in post from 2011-12-06)

Summary (diff b, vs c,):
========================
The b, patch fixed the issue only in private messages. Patch c, is fixing the issue
also in channel messages (with similar logic).

Mark, can you confirm, the CVE-2011-3594 issue would be exploitable to cause the
same harm in channel messages (intended to be fixed by new patch) as in private
messages (already contained within patch b,)?

Asking, because this is true (basically same nature issue, just being present
in different source code part), this would need a fourth CVE identifier
(as incomplete fix for CVE-2011-3594 issue).

Could you confirm the channel source code is impersonates the same concern
as private messages issue?

Once, confirmed I would allocate the fourth CVE identifier for channel messages
issue too (so it can be fixed by Linux distribution vendors, who have had already
applied original patch for CVE-2011-3594 issue).

CVE recapitulation:
===================
i)   first CVE -- XMPP/Jingle issue. Going to be assigned by Red Hat,
ii)  second CVE -- OSCAR UTF-8 issue. Going to be requested via OSS-security
      once public,
      One note here: Are we sure, we are fixing both instances (private vs
      channel OSCAR messages)?,
iii) third CVE - CVE-2011-3594 - SILC protocol private messages UTF-8 deficiency,
      leading to crash. Already assigned,
iv)  fourth CVE - SILC protocol channel messages UTF-8 deficiency. Going to be
      assigned by Red Hat once confirmed.

Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Response Team