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.

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.

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.