Multiple remotely-triggerable crashes in libpurple

[Jan Lieskovsky]

Hello John,

   thank you for the heads-up / preliminary notification.

John Bailey wrote:
> The following information is non-public and is to be considered confidential
> until the release of Pidgin 2.7.4 is made public.
> 
> Several security vulnerabilities have been discovered in libpurple.  All of
> these vulnerabilities were discovered by Daniel Atallah, one of our co-lead
> developers, and all stem from misuse of libpurple API (no validation of return
> values).  Daniel discovered this while investigating the crash associated with
> our trac ticket #12614 [1].
> 
> The vulnerabilities are all NULL-pointer dereference crashes and are as follows:
>   * Yahoo protocol plugin
>     * An invalid base64 value related to a buddy icon transfer is received
>       and an uninitialized variable passed by reference and used for length
>       has a non-zero value
>     * An invalid base64 value intended to contain an IP address used for a
>       peer-to-peer connection is received and an uninitialized variable
>       passed by reference and used for length has a non-zero value
>   * MSN protocol plugin
>     * An invalid base64 file transfer header is received and an uninitialized
>       variable passed by reference and used for length has a value greater
>       than the size of a struct
>   * MySpace protocol plugin
>     * An invalid base64-encoded login challenge is received
>   * XMPP protocol plugin
>     * An invalid base64-encoded Digest-MD5 authentication challenge is
>       received (this crash can happen only when Cyrus SASL is not available
>       or does not provide Digest-MD5 support)
>   * libpurple NTLM authentication support
>     * An invalid base64 "Type 2" message is received
> 
> The cause of these crashes is lack of validation of the return value produced by
> the purple_base64_decode() function.  We believe these are crashes only and not
> exploitable for code execution.
> 
> Attached to this message is a patch, written by Daniel, believed to fix the
> crashes described above.  In addition there are some minor fixes to the QQ
> protocol plugin and perl loader plugin.  While the perl loader has an instance
> of not validating the return value from purple_base64_decode, both it and the QQ
> protocol plugin also do not validate the return value of purple_base16_decode().
>  These issues are crashes as well, but to the best of our knowledge not remotely
> triggerable and thus not items we would consider vulnerabilities.
> 
> Because these vulnerabilities lie in libpurple, Pidgin, Finch, and Adium are
> also affected.  We know with certainty that these vulnerabilities exist in
> libpurple version 2.7.3 and thus are present in the same Pidgin and Finch
> versions.  Adium's current nightly builds should be affected, but we have not
> confirmed this.  We believe, but have not confirmed, that these vulnerabilities
> exist in earlier versions as well.  If they are indeed present in earlier
> versions of libpurple, it is likely that all currently-distributed versions of
> Pidgin, Finch, and Adium are affected.  Additionally, any other software using
> libpurple would naturally be affected.  We recommend that packagers actively
> supporting older versions of Pidgin, Finch, or libpurple evaluate their current
> packages to determine if the vulnerabilites are present.
> 
> We are currently in string freeze for a planned release on 2010-10-20.  This
> patch has not been committed to our public monotone repository; I will be
> privately committing this closer to the 20th and managing the release process.
> I expect to have a release tarball ready by 12:00 PM US EDT on the 20th, with
> the release being made public after 11:30 PM US EDT that evening.  I will
> provide a testing tarball next weekend to facilitate fixing any issues that may
> appear in your packaging processes, with the expectation that the only material
> changes thereafter will be the version number and any trailing translation updates.
> 
> Because these crashes are remotely triggerable, we believe we should have a CVE
> ID for them.  I'm hoping we need only one since each crash has the same root
> cause, but if individual CVE ID's are necessary for each crash described above
> we will note them appropriately.  If anyone on this list is able to provide us
> with the appropriate CVE ID(s), we'd greatly appreciate it!

   Please use CVE-2010-3711 to reference these flaws in your advisory.

   Only one of them was assigned, since the true reason for all of the
issues is the same for all of the above.

   Are there any reproducer / proof of concept files, which could be used for
patch work verification and updated packages testing purposes?

   If they are available, would you be willing to privately [1] share them with us?

[1] http://www.redhat.com/security/team/key/

   Also wondering about other vendors notification, do you have a plan to post
a short note regarding the issues to the vendor-sec channel?

   Providing basic issue details (i.e. multiple NULL pointer dereference flaws
leading to pidgin DoS, mentioning CVE id and preliminary / proposed embargo date,
together with patch should be enough as post there).

   Alternatively, we can send a short note regarding the issues to the vendor-sec
channel, just let us know you expect us to do so.

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

> 
> [1] http://developer.pidgin.im/ticket/12614
> 
> Thanks,
> 
> John
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Packagers mailing list
> Packagers at pidgin.im
> http://pidgin.im/cgi-bin/mailman/listinfo/packagers