Lucene search

K
freebsdFreeBSD38F213B6-8F3D-4067-91EF-BF14DE7BA518
HistoryJan 17, 2023 - 12:00 a.m.

libXpm -- Issues handling XPM files

2023-01-1700:00:00
vuxml.freebsd.org
11

8.8 High

CVSS3

Attack Vector

NETWORK

Attack Complexity

LOW

Privileges Required

LOW

User Interaction

NONE

Scope

UNCHANGED

Confidentiality Impact

HIGH

Integrity Impact

HIGH

Availability Impact

HIGH

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

6.5 Medium

CVSS2

Access Vector

NETWORK

Access Complexity

LOW

Authentication

SINGLE

Confidentiality Impact

PARTIAL

Integrity Impact

PARTIAL

Availability Impact

PARTIAL

AV:N/AC:L/Au:S/C:P/I:P/A:P

0.005 Low

EPSS

Percentile

75.2%

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.

OSVersionArchitecturePackageVersionFilename
FreeBSDanynoarchlibxpm< 3.5.15UNKNOWN

8.8 High

CVSS3

Attack Vector

NETWORK

Attack Complexity

LOW

Privileges Required

LOW

User Interaction

NONE

Scope

UNCHANGED

Confidentiality Impact

HIGH

Integrity Impact

HIGH

Availability Impact

HIGH

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

6.5 Medium

CVSS2

Access Vector

NETWORK

Access Complexity

LOW

Authentication

SINGLE

Confidentiality Impact

PARTIAL

Integrity Impact

PARTIAL

Availability Impact

PARTIAL

AV:N/AC:L/Au:S/C:P/I:P/A:P

0.005 Low

EPSS

Percentile

75.2%