Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <4F291A3A.8040000@redhat.com>
Date: Wed, 01 Feb 2012 11:55:54 +0100
From: Jan Lieskovsky <jlieskov@...hat.com>
To: "Steven M. Christey" <coley@...us.mitre.org>
CC: oss-security@...ts.openwall.com, berkeviktor@....com,
        Debian Security Team <security@...ian.org>,
        Paul Wise <pabs@...ian.org>, Joerg Reisenweber <joerg@...nmoko.org>,
        Christopher Aillon <caillon@...hat.com>,
        Remi Collet <Fedora@...illeCollet.com>,
        Jonathan Blandford <jrb@...hat.com>
Subject: CVE Request (two ids) -- Xchat-WDK (prior 1499-4 [2012-01-18]) and
 Xchat-v2.8.6 on Maemo architecture -- Heap-based buffer overflow by processing
 UTF-8 line from server containing characters outside BMP

Hello Kurt, Steve, Viktor, vendors,

   a heap-based buffer overflow flaw was found in the way xchat, graphical IRC
chat client, processed one line of text received from the server, when the text
contained Unicode characters and some of the characters were outside of the
Basic Multilingual Plane (BMP). A remote attacker could provide a
specially-crafted Unicode string as a xchat channel or private message, which
once processed would lead to denial of service (xchat client crash), or,
potentially arbitrary code execution with the privileges of the user running
xchat client.

This issue has been successfully reproduced on Xchat-WDK versions prior to:
* 1499-4 (2012-01-18)

     add Non-BMP plugin to avoid client crashes

version. Also Joerg Reisenweber reports, this deficiency to have been exploited
in the past on Xchat-v2.8.6 versions, as being used on Maemo architecture.

The following Linux based xchat versions have been investigated against presence
of this issue:
* xchat-v2.6.6,
* xchat-v2.8.6,
* xchat-v2.8.8

on various architectures (i386, x86_64, ppc64) with various versions of gtk2 library:
* gtk-v2.10.4,
* gtk-v2.18.9,
* gtk-v2.24.7,
* gtk-v2.14.7

and presence of this flaw has not been observed on those Linux versions, which makes
us think it is some Microsoft Windows 7 / Maemo architecture specific feature, which
makes this issue to be visible on those Xchat derivatives.

References:
[1] http://code.google.com/p/xchat-wdk/issues/detail?id=132
[2] http://code.google.com/p/xchat-wdk/issues/detail?id=134
[3] http://code.google.com/p/xchat-wdk/issues/detail?id=135
[4] https://bugzilla.redhat.com/show_bug.cgi?id=786391

Xchat-WDK upstream changelog:
[5] http://www.xchat-wdk.org/home/changelog
     part:
     * 1499-4 (2012-01-18)

     add Non-BMP plugin to avoid client crashes

Particular Xchat-WDK upstream patch:
[6] http://lwsitu.com/xchat/replace_non-bmp.diff

Could you allocate two CVE ids for these flaws? (assuming two ids are
necessary, because Xchat-WDK for MS Windows 7 case and Xchat-v2.8.6 for
Maemo case can / should be considered as different source code bases).

Steve, please advise if one id is sufficient or two should be used?

Also, for the Xchat-WDK case it looks that v1499-6 corrected the issue
for channel messages, but the issue is still present for 'private messages'
case:
[7] http://code.google.com/p/xchat-wdk/issues/detail?id=132#c33
[8] http://code.google.com/p/xchat-wdk/issues/detail?id=132#c34
[9] http://code.google.com/p/xchat-wdk/issues/detail?id=132#c36

Though this assumption needs to be verified / confirmed yet.
Viktor, could you please confirm or disprove it?

If that assumption would have shown as valid, a third CVE identifier
would need to be assigned yet for the incomplete Xchat-WDK v1499-6
fix yet (addressing the issue for 'channel messages' case, but not
for 'private messages' case).

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

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.