ef253f8b-0727-11d9-b45d-000c41e2cdad | xpm -- image decoding vulnerabilities
Chris Evans discovered several vulnerabilities in the libXpm
image decoder:
- A stack-based buffer overflow in xpmParseColors
- An integer overflow in xpmParseColors
- A stack-based buffer overflow in ParsePixels and
ParseAndPutPixels
The X11R6.8.1 release announcement reads:
This version is purely a security release, addressing
multiple integer and stack overflows in libXpm, the X
Pixmap library; all known versions of X (both XFree86
and X.Org) are affected, so all users of X are strongly
encouraged to upgrade.
Discovery 2004-09-15 Entry 2004-09-15 Modified 2005-01-03 agenda-snow-libs
linux_base
open-motif-devel
mupad
zh-cle_base
ge 0
libXpm
< 3.5.1_1
XFree86-libraries
< 4.4.0_1
xorg-libraries
< 6.7.0_2
lesstif
< 0.93.96,2
xpm
< 3.4k_1
linux-openmotif
< 2.2.4
open-motif
< 2.2.3_1
CVE-2004-0687
CVE-2004-0688
http://freedesktop.org/pipermail/xorg/2004-September/003172.html
http://scary.beasts.org/security/CESA-2004-003.txt
537878
882750
|
38f213b6-8f3d-4067-91ef-bf14de7ba518 | libXpm -- Issues handling XPM files
The X.Org project reports:
- 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
- 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
- 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.
Discovery 2023-01-17 Entry 2023-03-23 libXpm
< 3.5.15
https://lists.x.org/archives/xorg-announce/2023-January/003312.html
CVE-2022-46285
CVE-2022-44617
CVE-2022-4883
|