[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <c06293a7-27cc-908c-df04-e15fb982f83a@oracle.com>
Date: Wed, 1 Feb 2023 15:03:50 -0800
From: Alan Coopersmith <alan.coopersmith@...cle.com>
To: oss-security@...ts.openwall.com
Cc: "X.Org Security Team" <xorg-security@...ts.x.org>
Subject: Re: Fwd: X.Org Security Advisory: Issues handling XPM
files in libXpm prior to 3.5.15
While it was not our intention to drop zero-day bugs on our fellow
open source project, I have been unable to find any way to communicate
with the maintainers of the OpenMotif project - the bug tracker and
forums linked on their website are defunct, and mail has gone unanswered.
Distros & others packaging the OpenMotif library (or the older commercial
Motif library) may wish to compare our changes to the files under the
src directory in libXpm with the corresponding files with an "Xpm" prefix
on the file name in the OpenMotif lib/Xm directory. For example:
https://gitlab.freedesktop.org/xorg/lib/libxpm/-/blob/master/src/parse.c
vs.
https://sourceforge.net/p/motif/code/ci/master/tree/lib/Xm/Xpmparse.c
I apologize for not considering this before releasing the X.Org advisory.
I'd helped remove that code from the Solaris 11 libXm and replace it with
calls to libXpm after the round of libXpm CVE's in 2004, so we wouldn't
have to fix every XPM CVE twice, and forgot that other platforms may not
have done so.
-Alan Coopersmith- alan.coopersmith@...cle.com
X.Org Security Response Team - xorg-security@...ts.x.org
On 1/17/23 08:47, Alan Coopersmith wrote:
> For the libXpm 3.5.15 release announcement, see:
> https://lists.x.org/archives/xorg-announce/2023-January/003313.html
>
>
> -------- Forwarded Message --------
> Subject: X.Org Security Advisory: Issues handling XPM files in libXpm prior to
> 3.5.15
> Date: Tue, 17 Jan 2023 08:41:00 -0800
> From: Alan Coopersmith <alan.coopersmith@...cle.com>
> To: xorg-announce@...ts.x.org
> CC: xorg@...ts.x.org
>
> X.Org Security Advisory: January 17, 2023
>
> Issues handling XPM files in libXpm prior to 3.5.15
> ===================================================
>
> Three issues have been found in the libXpm library code to read XPM files
> in libXpm 3.5.14 and earlier releases.
>
> 1) CVE-2022-46285: Infinite loop on unclosed comments
>
> When reading XPM images from a file with libXpm 3.5.14 or older, if a
> comment in the file is not closed (i.e. a C-style comment starts with
> "/*" and is missing the closing "*/"), the ParseComment() function will
> loop forever calling getc() to try to read the rest of the comment,
> failing to notice that it has returned EOF, which may cause a denial of
> service to the calling program.
>
> This issue was found by Marco Ivaldi of the Humanativa Group's HN Security team.
>
> The fix is provided in
> https://gitlab.freedesktop.org/xorg/lib/libxpm/-/commit/a3a7c6dcc3b629d7650148
>
> 2) CVE-2022-44617: Runaway loop on width of 0 and enormous height
>
> When reading XPM images from a file with libXpm 3.5.14 or older, if a
> image has a width of 0 and a very large height, the ParsePixels() function
> will loop over the entire height calling getc() and ungetc() repeatedly,
> or in some circumstances, may loop seemingly forever, which may cause a denial
> of service to the calling program when given a small crafted XPM file to parse.
>
> This issue was found by Martin Ettl.
>
> The fix is provided in
> https://gitlab.freedesktop.org/xorg/lib/libxpm/-/commit/f80fa6ae47ad4a5beacb28
> and
> https://gitlab.freedesktop.org/xorg/lib/libxpm/-/commit/c5ab17bcc34914c0b0707d
>
> 3) CVE-2022-4883: compression commands depend on $PATH
>
> By default, on all platforms except MinGW, libXpm will detect if a filename
> ends in .Z or .gz, and will when reading such a file fork off an uncompress
> or gunzip command to read from via a pipe, and when writing such a file will
> fork off a compress or gzip command to write to via a pipe.
>
> In libXpm 3.5.14 or older these are run via execlp(), relying on $PATH
> to find the commands. If libXpm is called from a program running with
> raised privileges, such as via setuid, then a malicious user could set
> $PATH to include programs of their choosing to be run with those privileges.
>
> This issue was found by Alan Coopersmith of the Oracle Solaris team.
>
> The fix is provided in
> https://gitlab.freedesktop.org/xorg/lib/libxpm/-/commit/515294bb8023a45ff91669
> and
> https://gitlab.freedesktop.org/xorg/lib/libxpm/-/commit/8178eb0834d82242e1edbc
>
> libXpm 3.5.15 includes fixes for all three of these issues. It also adds
> a new configure option --disable-open-zfile that makes it easy for people
> building libXpm to completely disable the code to fork compression and
> uncompression programs if they do not have a need for it in their use case.
>
> X.Org thanks all of those who reported and fixed these issues, and those
> who helped with the review and release of this advisory and these fixes.
>
> The X.Org security team would like to take this opportunity to remind X client
> authors that current best practices suggest separating code that requires
> privileges from the GUI, to reduce the risk of issues like CVE-2022-4883.
>
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.
