CVE-2023-43785 is a security bug that you should know about if you use Linux or any system with the X Window System (X11). This vulnerability was found in libX11, the core library for X11, and lets local users trigger an out-of-bounds read and peek into system memory. Below, we’ll break down how this bug works, look at some code, and point you to original resources for more information.

What is libX11?

libX11 is the official client library for X11, the window system behind the graphics in many Linux desktops. Many programs rely on this library to create windows and interact with the graphics environment.

The Problem: Bug in _XkbReadKeySyms()

This vulnerability is all about a “boundary condition” error inside a function called _XkbReadKeySyms() in libX11. In plain language, this means the function doesn’t properly check how much data it’s handling. This oversight lets a local attacker read memory they shouldn’t be able to see—sometimes grabbing passwords, keys, or just causing a crash.

The bug was reported to affect libX11 versions up to 1.8.6. If you’re not running the latest version, you could be at risk.

Patch Status

This issue was fixed in libX11 version 1.8.7 and above. Here’s the official fixing commit. Always update your packages!

Technical Details

When a program calls certain X Keyboard Extension (XKB) functions, libX11 may receive keyboard mapping data over the network or from the local X server. The vulnerable _XkbReadKeySyms() function copies key symbols from a buffer into an array, but doesn't check the boundaries properly.

The Vulnerable Code

Here’s a simplified snippet similar to what was in the vulnerable version—note the lack of bounds checking:

static void _XkbReadKeySyms(FILE *file, int num, KeySym *syms) {
    int i;
    for (i = ; i < num; i++) {
        fread(&syms[i], sizeof(KeySym), 1, file);
        // No check if syms[i] is within the proper bounds!
    }
}

If num is bigger than the syms array size, the code reads and writes past the end of the buffer. When the data source is controlled by a local user (for example, running a custom X server), it’s possible to trick the function into reading contents from outside the intended buffer.

Exploit Example

An attacker who can run local code could set up their own X server (or intercept X traffic) and provide malicious keyboard map data. This can result in arbitrary memory areas being read and leaked back to the attacker.

Here’s a pseudo-exploit in C illustrating the type of attack

#include <stdio.h>
#include <stdlib.h>
#include <X11/XKBlib.h> // Make sure you have libX11-dev installed

int main() {
    Display *dpy = XOpenDisplay(NULL);
    if (!dpy) {
        printf("Cannot open display!\n");
        exit(1);
    }

    // Malicious code would interact with keyboard extension in a way that
    // provides more keysyms than expected, triggering the bug.
    // (In real exploit, attacker controls X server handshake.)

    XkbDescRec *kbdDesc = XkbAllocKeyboard();
    XkbGetMap(dpy, XkbAllMapComponentsMask, kbdDesc);
    // If the X server sends extra data, _XkbReadKeySyms() will over-read.

    XCloseDisplay(dpy);
    return ;
}

This is a demonstration only. In practice, an attacker needs to control the X server or communicate with an X client in a privileged context—most often via a local session.

How to Protect Yourself

- Update your system! Patch to libX11 1.8.7 or newer (download link).

References

- X.Org Security Advisory
- NVD Entry for CVE-2023-43785
- libX11 Gitlab Issue #227
- Official Patch Commit

Summary

CVE-2023-43785 is a boundary-checking bug in libX11’s _XkbReadKeySyms() function. Local attackers can use this to read memory they shouldn’t be able to, which could expose sensitive data. This bug is fixed in libX11 1.8.7 and later, so updating your system is key. Always keep your system updated and restrict local code execution where possible.

If you want more details, dig into the references or check out the libX11 codebase. Stay safe!

Timeline

Published on: 10/10/2023 13:15:21 UTC
Last modified on: 11/07/2023 04:21:29 UTC