A heap-based buffer overflow flaw was found in the way the SILC Purple Pidgin
protocol plug-in escaped certain UTF-8 private messages. If a Pidgin client
received a specially-crafted SILC message, it could cause Pidgin to crash, or,
potentially lead to arbitrary code execution with the privileges of the user
Updated the bug summary only. Reading the upstream ticket, I believe 2.10.0 is affected. 2.10.1 *may* include this fix, but as always, we'll wait and see.
@underling: Correct, sorry about that.
@net-im: Looks like a fix is available.
From oss-security http://www.openwall.com/lists/oss-security/2011/10/01/1 :
"This bug is believed to affect all releases of libpurple up to and
including version 2.10.0.
The correct fix for this bug is UTF-8 validation (and correction if
necessary) of the incoming string before passing it to Glib. A patch
which provides this fix has been applied to the Pidgin sources in
revision 7eb1f6d56cc58bbb5b56b7df53955d36b9b419b8 and will appear in
all future Pidgin releases. For reference, it is:
All packagers of libpurple (including monolithic Pidgin and/or finch
packages) who have not already done so are encouraged to apply this
change to their packages immediately."
Patch was added in 2.10.0-r1. Arch teams, please, stabilize.
amd64: all ok
Please remove -g from CFLAGS for the next release.
Upstream changed the info about the bug.
Please take a look at: https://secunia.com/advisories/46298/
Changing From B1 to B3
Stable for HPPA.
amd64 done. Thanks Elijah
*** Bug 385657 has been marked as a duplicate of this bug. ***
Thanks, folks. GLSA Vote: yes.
Vote: YES. Added to pending GLSA request.
The g_markup_escape_text function in the SILC protocol plug-in in libpurple
2.10.0 and earlier, as used in Pidgin and possibly other products, allows
remote attackers to cause a denial of service (crash) via invalid UTF-8
sequences that trigger use of invalid pointers and an out-of-bounds read,
related to interactions with certain versions of glib2.
This issue was resolved and addressed in
GLSA 201206-11 at http://security.gentoo.org/glsa/glsa-201206-11.xml
by GLSA coordinator Stefan Behte (craig).