X.Org Flaw Allows Privilege Escalation in Linux Systems

The issue impacts many large distros with GUI interfaces.

A local privilege-escalation and file-overwrite vulnerability in X.Org X server opens the door to trivial compromise in Linux systems that use the open-source software.

The X server is a core graphics and windowing technology that can be found in most Linux and BSD distributions that use a graphical user interface (GUI). The vulnerability (CVE-2018-14665) affects X server versions 1.19 and later, and has been around for at least two years. X.Org explained that if a vulnerable version of X.org runs on a system as “setuid” root, a logged-in user can use it to gain administrator-level privileges on the machine. From there, the user can create or overwrite files, anywhere on the system, including files owned by privileged users (i.e., an adversary could tamper with data or install malware).

Uncovered by security researcher Narendra Shinde, the issue arises because of an “incorrect command-line parameter validation.” Essentially, the system doesn’t check for correct permissions when someone uses the -modulepath or -logfile command line switches. Both are root-privileged X.org processes.

Red Hat issued its own report, describing the vulnerability as “an incorrect permission check for -modulepath and -logfile options when starting X.Org.” As such, “X server allows unprivileged users with the ability to log in to the system via physical console to escalate their privileges and run arbitrary code under root privileges.”

In the case of -modulepath, a user can inject code into the process; while the -logfile command can be used to overwrite the “shadow” password file so that the root user can log on without authentication.

“Overwriting /etc/shadow with -logfile can also lead to privilege-elevation since it’s possible to control some part of the written log file, for example using the -fp option to set the font search path (which is logged) and thus inject a line that will be considered as valid by some systems,” X.Org said in a mailing list post last week.

The attacker needs to already have an active console session going in order to successfully exploit the problem, according to Shinde — so in other words, the vulnerability won’t let an attacker gain initial access to the system. He explained in a separate posting that “unpatched systems can be exploited by non-root users if X server is running with elevated privileges.”

Other researchers noted however that when used in combination with other exploits, it’s possible for adversaries to gain complete control if they already have a lower privileged account.

Matthew Hickey of the Hacker House for instance shared a proof-of-concept exploit on Twitter, noting that the flaw is easy to exploit: “CVE-2018-14665 can be triggered from a remote SSH session, does not need to be on a local console. An attacker can literally take over impacted systems with 3 commands or less.”

The issue was also confirmed by security researcher Brendan Coles as working on CentOS 7.4, though he called the scenario “unlikely” given the need for an attacker to already have access to the system.

A patch is available in the X server repository, and many distros, including OpenBSDRed HatUbuntuDebianSUSE and Fedora, have issued their own advisories. X.Org also said that there’s a workaround:

“If a patched version of the X server is not available, X.Org recommends to remove the setuid bit (ie chmod 755) of the installed Xorg binary. Note that this can cause issues if people are starting the X window system using the ‘startx’, ‘xinit’ commands or variations thereof.”

Linux distros that don’t use X.org with elevated privileges are immune from the flaw.

Security firm Tenable issued its own assessment: “Because of the limited range of affected versions and the specific and often non-default configurations required to trigger this exploit, the attack’s scope appears to be narrow. However, it’s likely that malicious individuals will still seek out vulnerable systems.”

 

Suggested articles

Discussion

  • Anonymous on

    "GUI interface"
    • Tara Seals on

      I actually did think about whether I should just say "GUI" as it's obviously redundant, but decided that it sounded too abrupt. I've amended it to simply spell out the acronym. :-)

Leave A Comment

 

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Subscribe to our newsletter, Threatpost Today!

Get the latest breaking news delivered daily to your inbox.