Slashdot Mirror
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.
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.
I am confused. Do those distros run X in root or wheel? I don't remember having to do this.
And are they saying other systems do app level sandboxing and prevent system level applications from writing wherever they like?
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.
Xouvert, Wayland, Y, DirectFB, SVGAlib, Fbdev, Mir, NeWS and so many others have failed to break the X curse on Linux.
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: /usr/X11R6/bin/Xorg
chmod u-s
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.
I have discovered a truly marvelous proof of killer sig, which this margin is too narrow to contain.
The X server, the software that runs on the local host, needs local root privileges to communicate directly with the graphics chipsets. So yes, the "/usr/bin/X" program typically runs as the root user.
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.
Depends, if you use xenodm on OpenBSD X runs as ID _x11 not root. If you use startx, it runs as root. I wonder if on Linux you use a display manager X may runs under another ID.
Login to your OpenBSD 6.4 box and:
# syspatch
Get/Verify syspatch64-001_xserver... 100% |***************| 1227 KB 00:00
Installing patch 001_xserver
There. All fixed now.
1% APY, No fees, Online Bank https://captl1.co/2uIErYq Don't let your $$$ sit in a no-interest acct.
...something more along the lines of "sender" and "displayer".
It's Unix and open source. Naming things badly is a defacto requirement.
"I have only been able to come up with one algorithm for creating Unix command names: think of a good English word to describe what you want to do, then think of an obscure near- or partial-synonym, throw away all the vowels, arbitrarily shorten what's left, and then, finally, as a sop to the literate programmer, maybe reinsert one of the missing vowels."
-- Rachael Padman
I don't always use unix-like operating systems; but when I do, I prefer FreeBSD.
There's a lot of overblown complaints about X, either form people very ignorant or with an axe to grind. Often the complaints are about old things for which there are more modern API calls, but because X calls them extensions (API wasn't a common term in 1987) people flip their shit.
X certainly isn't prefect, it's warty in places but very battle tested and does a lot. Often half the features aren't interesting to someone, so the supposed replacements don't implement them, but it turns out not everyone's use case is the same.
SJW n. One who posts facts.
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).
The other problem is that doesn't solve any real problem but takes a away features. A lot of people where misled to believe that here a huge performance gains or other advantages to be gained from switching away from X. But those are mostly based on myths on how about X works (e.g. the idea that extensions unused by modern apps somehow constrain them). Of course, Wayland just reimplements a small subset of X in a very similar way, so performance is essentially the same.
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.
When all you have is a hammer, every problem starts to look like a thumb.
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.
When all you have is a hammer, every problem starts to look like a thumb.
It's not backwards if you accept the simple fact that the server is the software part which have multiple clients and will render the result onto hardware whereas it's clients are all the programs which want to draw something.