FreshPorts - VuXML

Matthieu Herrb reports:

Tobias Stoeckmann from the OpenBSD project has discovered a number of issues in the way various X client libraries handle the responses they receive from servers, and has worked with X.Org's security team to analyze, confirm, and fix these issues. These issue come in addition to the ones discovered by Ilja van Sprundel in 2013.

Most of these issues stem from the client libraries trusting the server to send correct protocol data, and not verifying that the values will not overflow or cause other damage. Most of the time X clients and servers are run by the same user, with the server more privileged than the clients, so this is not a problem, but there are scenarios in which a privileged client can be connected to an unprivileged server, for instance, connecting a setuid X client (such as a screen lock program) to a virtual X server (such as Xvfb or Xephyr) which the user has modified to return invalid data, potentially allowing the user to escalate their privileges.

< 1.6.4,1

< 5.0.3

< 1.7.7,1

< 1.5.1

< 0.9.10

< 1.2.3

< 1.0.11,1

< 1.0.10

The X.Org project reports:

CVE-2023-43785: out-of-bounds memory access in _XkbReadKeySyms()

When libX11 is processing the reply from the X server to the XkbGetMap request, if it detected the number of symbols in the new map was less than the size of the buffer it had allocated, it always added room for 128 more symbols, instead of the actual size needed. While the _XkbReadBufferCopyKeySyms() helper function returned an error if asked to copy more keysyms into the buffer than there was space allocated for, the caller never checked for an error and assumed the full set of keysyms was copied into the buffer and could then try to read out of bounds when accessing the buffer. libX11 1.8.7 has been patched to both fix the size allocated and check for error returns from _XkbReadBufferCopyKeySyms().

CVE-2023-43786: stack exhaustion in XPutImage

When splitting a single line of pixels into chunks that fit in a single request (not using the BIG-REQUESTS extension) to send to the X server, the code did not take into account the number of bits per pixel, so would just loop forever finding it needed to send more pixels than fit in the given request size and not breaking them down into a small enough chunk to fit. An XPM file was provided that triggered this bug when loaded via libXpm's XpmReadFileToPixmap() function, which in turn calls XPutImage() and hit this bug.

CVE-2023-43787: integer overflow in XCreateImage() leading to a heap overflow

When creating an image, there was no validation that the multiplication of the caller-provided width by the visual's bits_per_pixel did not overflow and thus result in the allocation of a buffer too small to hold the data that would be copied into it. An XPM file was provided that triggered this bug when loaded via libXpm's XpmReadFileToPixmap() function, which in turn calls XCreateImage() and hit this bug.i

< 1.8.7

The freedesktop.org project reports:

The functions XGetFontPath, XListExtensions, and XListFonts are vulnerable to an off-by-one override on malicious server responses. The server replies consist of chunks consisting of a length byte followed by actual string, which is not NUL-terminated. While parsing the response, the length byte is overridden with '\0', thus the memory area can be used as storage of C strings later on. To be able to NUL-terminate the last string, the buffer is reserved with an additional byte of space. For a boundary check, the variable chend (end of ch) was introduced, pointing at the end of the buffer which ch initially points to. Unfortunately there is a difference in handling "the end of ch". While chend points at the first byte that must not be written to, the for-loop uses chend as the last byte that can be written to. Therefore, an off-by-one can occur.

The length value is interpreted as signed char on many systems (depending on default signedness of char), which can lead to an out of boundary write up to 128 bytes in front of the allocated storage, but limited to NUL byte(s).

If the server sends a reply in which even the first string would overflow the transmitted bytes, list[0] (or flist[0]) will be set to NULL and a count of 0 is returned. If the resulting list is freed with XFreeExtensionList or XFreeFontPath later on, the first Xfree call is turned into Xfree (NULL-1) which will most likely trigger a segmentation fault. Casting the length value to unsigned char fixes the problem and allows string values with up to 255 characters.

< 1.6.6,1

The X.org project reports:

The X Input Method (XIM) client implementation in libX11 has some integer overflows and signed/unsigned comparison issues that can lead to heap corruption when handling malformed messages from an input method.

< 1.6.9_3,1

freedesktop.org reports:

Ilja van Sprundel, a security researcher with IOActive, has discovered a large number of issues in the way various X client libraries handle the responses they receive from servers, and has worked with X.Org's security team to analyze, confirm, and fix these issues.

Most of these issues stem from the client libraries trusting the server to send correct protocol data, and not verifying that the values will not overflow or cause other damage. Most of the time X clients & servers are run by the same user, with the server more privileged from the clients, so this is not a problem, but there are scenarios in which a privileged client can be connected to an unprivileged server, for instance, connecting a setuid X client (such as a screen lock program) to a virtual X server (such as Xvfb or Xephyr) which the user has modified to return invalid data, potentially allowing the user to escalate their privileges.

The vulnerabilities include:

Integer overflows calculating memory needs for replies.

Sign extension issues calculating memory needs for replies.

Buffer overflows due to not validating length or offset values in replies.

Integer overflows parsing user-specified files.

Unbounded recursion parsing user-specified files.

Memory corruption due to unchecked return values.

< 1.6.0

< 1.3.2

< 5.0.1

< 1.7_1

< 1.1.3

< 1.0.2

< 1.4.1

< 0.9.7_1

< 1.0.7

< 1.2.2

< 1.0.8

< 1.0.7_1

< 1.1.4

< 1.1.3

< 1.9.1

< 7.6.1_4

gt 7.8.0 lt 8.0.5_4

< 0.3.3

< 1.0.5

< 1.1.3

< 1.1.4

< 1.1.14

The X.org project reports:

XLookupColor() and other X libraries function lack proper validation of the length of their string parameters. If those parameters can be controlled by an external application (for instance a color name that can be emitted via a terminal control sequence) it can lead to the emission of extra X protocol requests to the X server.

< 1.7.1,1

The X.Org project reports:

• Buffer overflows in InitExt.c in libX11 prior to 1.8.6 [CVE-2023-3138]

  The functions in src/InitExt.c in libX11 prior to 1.8.6 do not check that the values provided for the Request, Event, or Error IDs are within the bounds of the arrays that those functions write to, using those IDs as array indexes. Instead they trusted that they were called with values provided by an Xserver that was adhering to the bounds specified in the X11 protocol, as all X servers provided by X.Org do.

  As the protocol only specifies a single byte for these values, an out-of-bounds value provided by a malicious server (or a malicious proxy-in-the-middle) can only overwrite other portions of the Display structure and not write outside the bounds of the Display structure itself. Testing has found it is possible to at least cause the client to crash with this memory corruption.

< 1.8.6,1

The X.org project reports:

There is an integer overflow and a double free vulnerability in the way LibX11 handles locales. The integer overflow is a necessary precursor to the double free.

< 1.6.12,1