Remotely-triggerable crash in oscar xstatus code

[Mark Doliner]

I believe I found a security problem (frowny face).  I'm going out of
town Sunday through July 4th and will have limited Internet access.
After someone confirms this problem and confirms that the attached
patch is a good fix, would anyone be willing to contact the packagers
list, provide this info, and request a CVE number?  I do not believe
this bug is known in the wild, so maybe we can set an embargo date
around July 10th?  I'm fine with making that soon or later.

As always, please do not disclose this information to the public
unless we have released fixed source and binary packages.

Full description:

This patch attempts to fix four bugs in the oscar protocol plugin that
were introduced with the X-Status code in Pidgin 2.7.0.

Problem #1 (the remotely-triggerable crash):
The crash happens when a buddy sets an xstatus message containing <desc>
but no closing </desc>, or <title> but no closing </title>.  The fix
is to check the result of strstr(closing_tag_name) and do nothing if it
is NULL.

Problem #2:
Fixes potential incorrect parsing of the xstatus string that could result
in an incorrect message being displayed to the libpurple user.  Happens if
an xstatus message contains </desc> before <desc>, or </title> before
<title>.  The fix is to start looking for the closing tag at the end
of the beginning tag rather than at the beginning of the xstatus xml.
Probably not a security problem, but definitely a bug.

Problem #3:
Fixes potential incorrect parsing of the xstatus string that could result
in the title not being shown to the libpurple user.  Happens if the close
title tag appears after the desc tag in the xstatus xml, because we add a
null character at the beginning of the close title tag, so strstr() for
the desc tag would stop searching there.  Probably not a security problem,
but definitely a bug.

Problem #4:
Fixes potential incorrect display of the xstatus string that could result
in an incorrect message being displayed to the libpurple user.  Happens
because we reusing the 'xml' string when preparing the string for the user,
but we copy values from xml to xml.  If those values overlap with themselves
or with each other then an incorrect value could be displayed.  Probably not
a security problem, but definitely a bug.

--Mark
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oscar_xstatus_remote_crash_fix_1.diff
Type: text/x-patch
Size: 4715 bytes
Desc: not available
URL: <http://pidgin.im/cgi-bin/mailman/private/security/attachments/20100618/cc1da370/attachment.bin>