Request for CVEs for Pidgin

[Mark Doliner]

Hi Red Hat security folk! This is Mark, a developer of Pidgin, Finch,
and libpurple. We're working on fixing some security problems. I hope
to disclose more details+patches to our standard packagers at pidgin.im
mailing list (which includes you) sometime in the next few days, with
a public embargo date of morning US Pacific time on Jan 23.

With the exception of one, these were all reported to us privately
over the past 12 months via our security at pidgin.im mailing list.
Sadly, this is a long list and we've been remiss in pushing out fixes
on a regular basis.

Could you please assign CVE numbers to us? (The listed ISSUE number is
solely for convenience in referencing them until they have proper CVE
numbers.)

-----

ISSUE-01, reported by Thijs Alkemade and Robert Vehse
Yahoo! remote crash from incorrect character encoding.
Many places in the Yahoo! protocol plugin assumed incoming strings
were UTF-8 and failed to transcode from non-UTF-8 encodings.  This can
lead to a crash when receiving strings that aren't UTF-8.

-----

ISSUE-02, reported by Jaime Breva Ribes
Crash handling bad XMPP timestamp.
A remote XMPP user can trigger a crash on some systems by sending a
message with a timestamp in the distant future.

-----

ISSUE-03, reported publicly on support at pidgin.im
(https://pidgin.im/pipermail/support/2013-March/012980.html)
Crash when hovering pointer over a long URL.
libX11 forcefully exits when Pidgin tries to create an exceptionally
wide tooltip window.

-----

ISSUE-04, discovered by Jacob Appelbaum of the Tor Project
Remote crash parsing HTTP responses.
A malicious server or man-in-the-middle could send a malformed HTTP
response that could lead to a crash.

-----

ISSUE-05, discovered by Daniel Atallah
Remote crash reading Yahoo! P2P message.
The Yahoo! protocol plugin failed to validate a length field before
trying to read from a buffer, which could result in reading past the
end of the buffer which could cause a crash.

-----

ISSUE-06, discovered by Fabian Yamaguchi and Christian Wressnegger of
the University of Goettingen
NULL pointer dereference parsing headers in MSN.
A malformed Content-Length header could lead to a NULL pointer dereference.

-----

ISSUE-07, discovered by Fabian Yamaguchi and Christian Wressnegger of
the University of Goettingen
NULL pointer dereference parsing OIM data in MSN.
A malicious server or man-in-the-middle could send us a
specially-crafted XML response that results in a NULL pointer
dereference.

-----

ISSUE-08, discovered by Fabian Yamaguchi and Christian Wressnegger of
the University of Goettingen
NULL pointer dereference parsing SOAP data in MSN.
A malicious server or man-in-the-middle could send us a
specially-crafted SOAP response that results in a NULL pointer
dereference.

-----

ISSUE-09, discovered by Fabian Yamaguchi and Christian Wressnegger of
the University of Goettingen
XMPP doesn't verify 'from' on some iq replies.
The XMPP protocol plugin failed to ensure that iq replies came from
the person they were sent to. A remote user could send a spoofed iq
reply and attempt to guess the iq id. This could allow an attacker to
inject fake data or trigger a null pointer dereference.

-----

ISSUE-10, discovered by Coverity static analysis
Crash reading response from STUN server.
Incorrect error handling when reading the response from a STUN server
could lead to a crash.

-----

ISSUE-11, discovered by Matt Jones, Volvent
Buffer overflow parsing chunked HTTP transfers.
A malicious server or man-in-the-middle could cause a buffer overflow
by sending a malformed HTTP response with chunked Transfer-Encoding
with invalid chunk sizes.

-----

The next vulnerability is the same as CVE-2011-3185. We failed to
adequately fix it at that time. Is it customary to reuse that CVE or
issue a new one?

ISSUE-12, discovered by Sourcefire VRT
Pidgin uses clickable links to untrusted executables.
If a user clicks on a file:// URI in a received IM in Windows builds
of Pidgin, Pidgin attempts to execute the file. This can be dangerous
if the file:// URI is a path on a network share.

-----

The following 3 vulnerabilities have the same pattern but are in
different pieces of code. My preference is to use a separate CVE for
each of them, but I seem to remember you preferring to share a CVE for
vulnerabilities with the same type of problem. Your call. The pattern
is: Read a value of "-1" from the network, call g_malloc(len + 1)
which returns NULL, then attempt to write data to NULL (aka the first
page of memory).

ISSUE-13, discovered by Sourcefire VRT
Buffer overflow in Gadu-Gadu HTTP parsing.
A malicious server or man-in-the-middle could send a large value for
Content-Length and cause an integer overflow which could lead to a
buffer overflow.

ISSUE-14, discovered by Sourcefire VRT
Buffer overflow in MXit emoticon parsing.
A specially crafted emoticon value could cause an integer overflow
which could lead to a buffer overflow.

ISSUE-15, discovered by Sourcefire VRT
Buffer overflow in SIMPLE header parsing.
A Content-Length of -1 could lead to a buffer overflow.

-----