Trivial Bug In X.Org Server Gives Root Permissions On Linux, BSD Systems (bleepingcomputer.com) 114
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.
So similar risk to accidentially typing 'sudo' (Score:1)
In other words, not much risk on single-user systems where the primary user is also the administrator. Recall that for decades the Windows default user had administrative privileges by design, without needing either sudo or a privilege escalation bug.
Re: So similar risk to accidentially typing 'sudo' (Score:2)
"In other words, not much risk on single-user systems where the primary user is also the administrator."
While many distros allow blanket passwordless sudo for the primary user, this isn't the only way privileges are managed.
For example, I set my systems up to allow only commonly used but safe commands that need root with passwordless sudo, if you want to run arbitrary commands, use the root password (which is stronger). Of course, remote root login with password is not enabled.
Re: (Score:2)
What do you mean, accidentally typing sudo? You will be asked for a password unless you have (insecurely) set up a nonstandard passwordless sudo configuration. How would you accidentally enter your password?
So the answer: no relation between the risks. But it looks to me that standard Xorg installs are not vulnerable because they are not normally installed with suid on the X server. My Debian system is certainly not configured that way. According to the advisory [x.org] the exploit is only possible if the X server
Re:So similar risk to accidentially typing 'sudo' (Score:4, Informative)
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 [debian.org] except for buster.
Re: (Score:2)
Not what I meant. I was talking about, e.g., school lab where students can login on console. Not too many of those around, to be honest.
Re: So similar risk to accidentially typing 'sudo' (Score:1)
You will be asked for a password
They accidentally entered that, too.
If this is a vulnerability; my programs have a lot (Score:3)
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?
Re: (Score:3, Insightful)
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.
Re:If this is a vulnerability; my programs have a (Score:5, Informative)
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: (Score:1)
Re: If this is a vulnerability; my programs have a (Score:2, Troll)
"Not surprised the terminology is backwards. The majority of Open Sores stuff is incredibly ass backwards"
I believe this terminology pre-dates open-source X implementations, and is used by all proprietary X implementations.
Try harder next time you try and troll ...
Re: (Score:2)
Like MS could have fixed having to include C: in filename-paths?
Sometimes unfortunate design-choices can have a long life. You're faced with the dilemma of being backward-compliant, or tearing everything out and starting over. Usually the best approach is somewhere in between these extremes.
Open-source owes much of its success to embracing unix, with all of its warts. I think of it in the same way Winston Churchill thought of democracy, as the worst possible operating system, with the exception of all other
Re: If this is a vulnerability; my programs have a (Score:2)
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.
Re: (Score:2)
Absolutely not backwards. It's serving resources and makes perfect sense for clients to request those resources.
Nevertheless, they should have avoided the terms "server" and "client" altogether because they are so strongly associated with types of hardware. Having the server run on client hardware and the client run on server hardware is just damned confusing.
I've known this factoid for decades, and I still have to stop and sort it out in my head it every time I see the term "X server". The only people who would think that this is "obvious" would be dedicated GUI developers, which is probably about 0.01% of the user
Re: If this is a vulnerability; my programs have a (Score:2)
Having the server run on client hardware and the client run on server hardware is just damned confusing.
X applications don't and generally haven't run on this 'server' hardware you speak of. Even way back in the era of X Terminals the machine an X application was run on was more likely in a peering relationship.
Re: (Score:2)
Whatever. Today, the client usually runs on the client hardware. Sometimes it runs on "peer" hardware. Sometimes it runs on server hardware. The server always runs on client hardware.
No matter what, it's a stupid ball of confusing terminology.
Re: (Score:1)
It's not 'stupid' just because you mistakenly think you know what it means.
Re: If this is a vulnerability; my programs have (Score:1)
Re: (Score:3)
Re: (Score:2)
Unix commands have been described as digestive noises, and a boon to two-finger typists. But the best explanation I have heard as to why they are so short and cryptic is that teletype terminals in the 1970s (when unix was developed) were slow, with keys that took some effort to press down. Reducing the number of characters you needed to type was helpful.
As unix moved onto CRT terminals with lighter-action keyboards, commands gradually got a bit longer. And sometimes improved commands got whimsical names, su
Re:If this is a vulnerability; my programs have a (Score:4, Insightful)
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: (Score:1)
Despite massive advances in security and security models, certain popular hardware conspicuously requires drivers that subvert the security model by still requiring Xorg to be run as root. Want to take a guess as to whose driver is the primary culprit here?
I'll give you a hint. It starts with N and ends with Vidia.
Re: (Score:3)
Still dependent on X after all these years. (Score:3, Interesting)
Re: (Score:2)
Re:Still dependent on X after all these years. (Score:5, Insightful)
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: (Score:2)
Me neither, but they would need to make it usable over WiFi. And do it 15 years ago.
But also fix the horrible mess that inter-application copy & paste is on X11. The Mac got it perfectly right in 1984.
Re: (Score:3)
What's wrong with copy and paste on X11?
The protocol essentially goes like this:
1. Client asserts it has copied data
2. Pastee requests data owner id from the server
3. Pastee asks owner for a list of data types it offers
4. Pastee asks owner for data of a given type and tells owner where to send it
5. Owner sends.
A few details. In 1 and 2 they have to name which buffer. This is usually PRIMARY, CLIPBOARD or one with Xdnd in the name for drag and drop operations. Others exist in theory, but only those 3 are rem
Re: (Score:1)
The problem is that in some applications middle click will paste something different than Shift+Insert.
Then there Ctrl-C, Ctrl-V which pastes something else again depending on the application.
The most annoying thing is programs where Ctrl-C doesn't work reliably but you are pasting into some text box that already has text in it.
So you have to clear the text box first, which replaces whatever you had selected since usually you have to select to to delete it quickly.
Then you go back to whatever other applicat
Re: (Score:2)
Not sure about shift+insert: that was the common sequence back in the old DOS days, it was never especially prevalent on Unix from what I recall.
I've not encountered any cases recent where I'd have expected ^C/V to work and it didn't (it doesn't in vim, but would anyone expect that? Vim supports X clipboards via the old named buffer mechanism from vi). Explicit copy/paste should always use the CLIPBOARD and select middle click should always use the PRIMARY buffer.
Old motif programs used Alt not control. Con
different pastes (Score:2)
Re: (Score:2)
Personally I love the dual clipboard mechanism. It seems that on their quest you first make Linux a cheap Windows knockoff, then make it a cheap OSX knockoff, the gnome people want to kill the middle click paste thing. They're never going to realise that Linux will not ever be a better Mac than Macs and perhaps they should stick to its merits instead.
FFS middle click paste isn't an Easter egg.
Re: (Score:2)
A year ago, when I had KDE, it had the kclipboard which I could use to have multiple clips, and then I could select which one I wanted to paste before pasting. While it was more versatile, it was less automatic for me. After I had to overhaul my TrueOS setup, I ended up w/ just Lumina, and now, I just live w/ the middle click and ctrl-v pastes. Yeah, I could install whatever clipboard TrueOS bundles in, but so far, I haven't seen the need.
As for GNOME, I've never liked either the version 2 nor the vers
Re: (Score:2)
I've not used gnu step since the late 90s I think! It looked cool, but I always went back to FVWM.
I know what you mean about clipboard managers. I too have flirted with them. It seems like a really cool idea and about every 7 years I get enthusiastic about it, set one up, lean the shortcuts and in about 3 weeks I find I'm simply not using it. There's a bunch of different ones, and I can't remember the ones I've tried. Thing is I think a clipboard is somewhat immediate in that I don't generally think in ter
Re: (Score:3)
I disagree. X is a beautifully engineered protocol which powerful, elegant, and extendable. Throwing it away and breaking compatibility with this ecosystem is the worst blunder Linux distributions could do. Also the security problem reported here is unrelated to the protocol,
Yes, modern apps use X in different way, but they are in now way limited by old extensions. People claiming that old unused extensions like server-side fonts constrain anything clearly do know how X work. If you think otherwise, please
Re: (Score:2)
All I know is what I've read and heard from guys who actually know X11, particularly X.org inside and out. The talk I was trying to remember is by Daniel Stone. https://www.youtube.com/watch?... [youtube.com] . Well worth the watch. He claims to be only one of maybe four people that actually understand the nitty gritty details of X.org, it's architecture, and X11's weaknesses.
Re: (Score:2)
Yeah, right... Daniel Stone of Wayland is the only one understanding X.
Re: (Score:2)
I don't even get what the big problems are at this point. Five years ago there was a laundry list but everybody expected it to be default three years ago.
This is a problem because everybody knows X11 ain't no good anymore but nobody is fixing it because Wayland (nee "x12") is the fix.
Can somebody describe or link some current info here?
Re: (Score:2)
This is a problem because everybody knows X11 ain't no good anymore but nobody is fixing it because Wayland (nee "x12") is the fix.
I'm going to disa
Re: (Score:2)
I must know, what is everyone doing remotely that they need X?
Re:Where is Wayland (Score:4, Interesting)
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: (Score:3)
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
Re: (Score:3)
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.
Privilege escalation unlikely (Score:5, Informative)
It's not about having Xorg being run as root (which is probably the case if you run an X display manager [wikipedia.org]), 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.
Re: (Score:2)
I'm afraid that X display managers are programs running on top of the X server, started shortly after the X server begins. I don't think they're a defense against this issue.
Re: (Score:3)
The point was that if your system is using a display manager, it's probably launched at system startup (because why would a user launch a display manager ?), which means the X server was launched as root, which means that Xorg doesn't need to be setuid.
I mentioned it as an easy heuristic. The "full" check is:
ls -l `which Xorg`
If there's an 's' in the permission mask, privilege escalation is possible.
Otherwise it's just arbitrary code execution with current user's rights, which is a less important issue (and
Re: (Score:2)
Thanks anon !
Indeed, when I tried to launch a second X session from my main session, in preparation of my answer to Guybrush_T below, I got the following error:
And that file is both setuid and setgid.
The man page mentions:
By default Xorg.wrap will autodetect if root rights are necessary, and if not it will drop its elevated rights before starting the real X server.
So Debian stretch is vulnerable in cases where Xorg.wrap decides Xorg needs root rights.
Re: (Score:2)
From TFA:
Re: (Score:2)
Some folks require remote (SSH) access to their workstation which unsurprisingly usually has an X server installed.
Re: (Score:2)
Your comment is confusing to me
Do you understand that I was responding to the statement quoted below?
Re: (Score:2)
I'm not sure how is an idiot, but what I find stupid is setting Xorg +s (which seems to be default in some *BSD distros !). Everything that is +s should be extremely simple and controlled programs. Not a huge complex blob like Xorg which certainly has a ton of other security holes.
Re: (Score:2)
The problem is that Xorg is pretty much tied to the kernel's video subsystem. Apart from changing the whole architecture, avoiding it running with full root rights implies having a capability-based security model.
Either Xorg doesn't support capabilities (which seems to be the case, when I try to launch a second X session as an user from the command line on my Debian it fails and the log mentions a permission denied accessing /dev/tty0), or the operating system doesn't implement them.
Therefore, while it's da
Re: (Score:2)
As a side note, I'm pretty sure that Xorg isn't shipped on a default OpenBSD install, so it would have to be installed first from the ports.
OpenBSD install media comes with binary distribution sets xbase**, xfont**, xserv**, xshare** (** being the version number, latest being 64 for version 6.4) for installing Xorg support which you can select when you install the OS.
Re: (Score:2)
From the man page [systutorials.com] "By default Xorg.wrap will only allow executing the real X server from login sessions on a physical console."
My reading is, you are only vulnerable if you hand your computer over to a black hat complete with login details. I don't know about you, but I never do that. Likewise, hosting is not vulnerable because no physical access. School and public library computers are vulnerable. Those would be rare.
BTW, fixed [debian.org] in jessie, stretch and sid, but not yet in buster.
Re: (Score:2)
You might want to check that again. True, /usr/bin/Xorg isn't a setuid file but it's just a shell script (so it can't be setuid anyway) which calls /usr/lib/xorg/Xorg.wrap (if it exists) which is setuid root. That then calls /usr/lib/xorg/Xorg which isn't setuid root.... or at least I'm assuming it does because Xorg.wrap is only 11k in size so it can't be the full server.
That's not what "trivial" means (Score:2)
A bug may be "trivial to exploit" (as in the summary), or it may be "trivial" because it is harmless. A "trivial bug" does not grant root.
OpenBSD syspatch already available (Score:3)
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.
Then my Sgi/Octane has some workload for today (Score:2)
Printer in Error State (Score:1)
Re: (Score:3, Informative)
Re: I thought Linux was the bastion of security (Score:1)
Thread over. rootless X has been around longer than this bug
Re: (Score:1)
For starters, it doesn't ship your data to India or erase it