Trivial Bug In X.Org Server Gives Root Permissions On Linux, BSD Systems (bleepingcomputer.com)

An anonymous reader quotes a report from Bleeping Computer: A vulnerability that is trivial to exploit allows privilege escalation to root level on Linux and BSD distributions using X.Org server, the open source implementation of the X Window System that offers the graphical environment. The flaw is now identified as CVE-2018-14665 (credited to security researcher Narendra Shinde). It has been present in xorg-server for two years, since version 1.19.0 and is exploitable by a limited user as long as the X server runs with elevated permissions.

An advisory on Thursday describes the problem as an "incorrect command-line parameter validation" that also allows an attacker to overwrite arbitrary files. Privilege escalation can be accomplished via the -modulepath argument by setting an insecure path to modules loaded by the X.org server. Arbitrary file overwrite is possible through the -logfile argument, because of improper verification when parsing the option. Apart from OpenBSD, other operating systems affected by the bug include Debian and Ubuntu, Fedora and its downstream distro Red Hat Enterprise Linux along with its community-supported counterpart CentOS.

Comments

Re:I thought Linux was the bastion of security

[Anonymous Coward]

Your comment is funnier than you think since logind which part of the systemd project allows for X.Org to run rootless which completely avoid this very issue.

Privilege escalation unlikely

[alexhs]

It's not about having Xorg being run as root (which is probably the case if you run an X display manager), but about the ability for a user to launch Xorg with root privileges (with the setuid bit).

On my Debian stretch, Xorg is not setuid, so there's no privilege escalation.

FTFA:

As a temporary solution, users can disable the Xorg binary by running the following command:
chmod u-s /usr/X11R6/bin/Xorg

Seriously, that guy is an idiot. Obviously doesn't understand what's a setuid bit and copy/pasting command lines as if it they were magic spells.

Re:If this is a vulnerability; my programs have a

[Waffle Iron]

The X server doesn't need direct access to the "graphics chipsets" (eg. the GPU). It is designed to run over network connections.

You've got it backwards, probably because of the unfortunate and counter-intuitive terminology they use.

The X server shows the graphics on the local terminal (which is usually the "client" hardware), and the X client is the interface used by the software application that can be running remotely (which is often on the "server" hardware). So the X server does need to access the GPU.

Re:Still dependent on X after all these years.

[caseih]

Well they got some things right like the ability of apps to run remotely. The rest, well probably not. 90% of the old X11 features we don't use anymore at all but those things constrain the protocol and architecture of X11. Things like server-side widgets, server-side fonts, etc. Given the constraints at the time, X11 was amazing. I remember running X11 programs remotely over a modem. And they were usable.

Modern apps use X11 differently and the desire for modern features like anti-aliased fonts mean that much of time X11 is relegated to nearly the level of a frame buffer. Apps render and composite on the client side, and then sent pixmaps to the server which displays them. Although this was all done keeping the ability to run apps remotely (more or less... there are limitations with things like accessing OpenGL). The asynchronous nature of the X11 protocol also makes it more challenging to make redraws and window moves happen without tearing. There was a good talk a few years ago on the architectural problems with X11 and how wayland (developed by former X11 developers) aimed to solve many of those problems.

It's clear to me that Wayland is the future, but until app remoting is a part of the package as it were, I'm not at all interested. And they had better keep things like middle-click paste. I'm not at all interested in client-side decorations either. Keep my window manager separate! There's nothing more annoying that a window that can't be moved because the program has stopped responding to events! So far Wayland looks like a big step forward in some ways, a big step backwards in others.

Re:Where is Wayland

[Uecker]

This is extremely useful to me. You can, log into a remote computer to use special software, or attached hardware, etc.. You can sit next to an arbitrary colleague and log into your computer showing some stuff or use the computer in the conference room to log into your computer running which runs some simulation and demonstrate live it in a presentation. It is just sad it is not supported more with moving windows or reconnecting which are both supported by X in the underlying protocol (I know I implemented proof-of-principle apps which do this, so please don't argue this would be impossible with X).

Re:If this is a vulnerability; my programs have a

[Tough Love]

they should have avoided the terms "server" and "client" altogether because they are so strongly associated with types of hardware

Sounds like you need to broaden your horizons a bit. "Server" describes a pattern of processing data, whether hardware or software. It is well established and well understood terminology, regardless of your particular preconception.

Re:So similar risk to accidentially typing 'sudo'

[Tough Love]

OK, it's more nuanced than that. The Xorg server isn't suid, but there is an Xorg.wrap binary that is suid, which provides xstart/xinit functionality from a physical console. So not exploitable remotely, e.g., ssh, but shared public Linux machines are vulnerable. Those would be rare, but admins better move to get them updated. Debian already has fixes except for buster.