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.
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.
Nobody is paying you to know that. It follows.
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.
Using a display manager makes this moot. How many systems use a display manager? Debian, Ubuntu, Fedora, CentOS, etc etc
How long does it take for Wayland not to be such a PoS?
For starters, it doesn't ship your data to India or erase it
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.
I like it when you set the bar so high right at the start!
The X server doesn't need direct access to the "graphics chipsets" (eg. the GPU). It is designed to run over network connections.
BleepingComputer is great, but that's one sloppy headline.
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.
The Daddy casts sleep on the Baby. The Baby resists!
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.
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.
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.
Not surprised the terminology is backwards. The majority of Open Sores stuff is incredibly ass backwards
Absolutely not backwards. It's serving resources and makes perfect sense for clients to request those resources.
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 base.
They should have used less loaded terms, maybe something more along the lines of "sender" and "displayer".
This is why all my builds when I was a Linux admin didnt install packages you didnt need. Still amazed at all the Linux servers I see running full desktop installs when nobody needs or uses it. You can still run X apps remote without local X server nitwits!
Thread over. rootless X has been around longer than this bug
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.
I have tried the exploit and read the article and have two things to add:
1. The article suggests running a chmod command to fix the issue. That command won't work on most platforms, I think it's OpenBSD-specific.
2. On my systems (Debian Stretch) the logfile exploit technically works, it creates the log file as advertised (shadow in the case of the example in the article). This happens even if root owns the file. However, the original file is saved as logfile.old (or shadow.old in the example). So the original is still available.
However, the exploit did not give my user root access.
But SystemD itself brings more issues, and Lennart Poettering is not gonna going to fix them.
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.
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.
...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.
It's not 'stupid' just because you mistakenly think you know what it means.
"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 ...
You think that makes it better? It could've been fixed, but it wasn't. Because Open Sores is ass backwards.
So you're saying Apache is a web client and Chrome is a web server. Good to know.
Hell, no!
Features like that cost money to implement.
recompiling the X.org server in #t2sde Linux; https://www.youtube.com/watch?... ;-)
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.
Wrong.
You can start X just fine as a non-root user Just open a VT as a non-root user and type startx.
Only if you use a graphical X based login manager does it have to run as root, and even then it could probably be avoided.
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.
Skynet becomes self-aware at 02:14 am Eastern Time after its activation on August 4, 1997 and spends the rest of eternity pitting arguments for and against the X server/client terminology.
nope you can add yourself to the video/input groups and setgid the binary and it will work fine
The only people who would think that this is "obvious" would be dedicated GUI developers, which is probably about 0.01% of the user base.
They should have used less loaded terms, maybe something more along the lines of "sender" and "displayer".
Back in the 80s those terms weren't that loaded yet.
Servers ran the listening socket, and clients connected to them.
More than just GUI developers, but pretty much all developers that ever used socket, network, pipe IPC, or much of anything beyond just opening a file to read already had this concept down pat.
I always assumed the original X11 developers always intended for the "over the network" features to be the big cheese so to speak.
It was primarily those of a time with the hardware able to run both on the same single computer that were most confused.
Swapping the two would have been a worse confusing nightmare and probably true to this day, although yea using completely new terms like you suggest would be the best way to go and simply do away with client/server.
ps -eo pid,euid | grep 1404
1404 0
So it didn't drop root.
That's a pretty big "attack surface" as they say.
When was the last time such a flaw was discovered?
You think that makes it better? It could've been fixed, but it wasn't. Because Open Sores is ass backwards.
It's a protocol, you twit. Stop trolling and fuck off.
If you have something actively highlighted, middle-click (or both bottons clicked) will paste that highlighted text. If you've copied something using ctrl-c, ctrl-v will paste that copied text. If that copied text is different from something else subsequently highlighted, ctrl-v and middle click will have different results. Something I find useful when I need to paste different things in different places w/o copying them multiple times
I knew it, just like clockwork. You guys are so transparent...
By talking to polkit over dbus, and dbus seems to have all kinds of issues (to the point that they wanted to cram it into the kernel to speed it up).
No, the X server do not!
It is up to the individual clients to access the GPU.
The mud in the water is the abuse of GPUs to drive window managers that in turn hijack the drawing of window content, supposedly to counteract various artifacts. Except that most of them go away when running everything synced to vertical blank (vsync). And the only people that refuse to do that are gamers that have e-peen contests about framerates (and thus the nvidia fans are the biggest complainers about "tearing" on Linux).
Gotta love how the people that insist on using nvidia hardware are also the same people complaining loudly about "tearing" in X because by default the proprietary drivers run with vsync disabled.
And yet Nvidia seems to have little interest in supporting the Wayland that is supposed to save everyone from seeing "tearing" ever again.
Fuck i hate the current gen of Linux "enthusiasts". Gamers and webdevs, all of them.
HTTP is also a protocol. SMTP is also a protocol. NTP is also a protocol. Tell me; if I ask ntp-b.nist.gov for the time, is it a time client, or a time server? Is Nginx a http client that delivers slashdot.org to the http server I'm currently using to type this reply, or is the other way around?
I'll stick with my safe and secure Windows installation. Plus there are no driver issues or lack of programs.
It just works!
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 others that have been tried and discarded.
If it weren't for deadlines, nothing would be late.
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, such as more evolving to less, and an improved man command being called woman.
Grudgingly, I must admit The Unix-Haters Handbook got it right:
A century ago, fast typists were jamming their keyboards, so engineers designed the QWERTY keyboard to slow them down. Computer keyboards don’t jam, but we’re still living with QWERTY today. A century from now, the world will still be living with rm.
If it weren't for deadlines, nothing would be late.
Nginx acts as a source of code, which mostly then runs on the client. Google will stream data from their server to your client to process. Mozilla is a client, it uses resources on the server to display things.
Similarly, in X (server) Mozilla is a client, which users the resources of the server to display things. The other machine isn't the client, the programs running on it are. It uses exactly the same client server scheme as every other bit of tech.
Why do you insist on trying to make X.org terminology different from every other setup in the world?
Is it because you're stupid? It is, isn't it?
Thanks for taking the time to discuss this topic. it really helpful to the user. Recently I bought a new laptop having window 10 and when i tried to connect my laptop to the printer it shows error then i decided to take assistance from Printer in Error State team through https://www.canonprintersuppor... and I took. They assisted me perfectly to resolved my issues. so, anybody facing any type of issues they can go through the same.