Re: And this is news how?
1. If you're providing a shared system - such as a university lab of Linux PCs - it's bad news.
2. It's an amusingly trivial bug to exploit.
3. Lurk more.
X.org, the X Window server used by various desktop Linux and BSD operating systems, has – depending on its configuration – a security vulnerability that can be exploited to gain root powers. If a vulnerable version of X.org runs on a system as setuid root, it can be abused by normal logged-in users to gain administrator-level …
I _ALWAYS_ use startx. I prefer to boot into a console. Many reasons exist. The fact is "boot into a GUI" irritates me on POSIX systems. I don't know what 'bright bulb' windows and/or systemD lover insisted on THAT as "the default", nor made it more difficult to "turn that @#$% off" in post-systemD-world, but that's another rant for another day...
I checked my FreeBSD server and it's an earlier Xorg (from slightly more than a year ago, 1.18.something). I did chmod 4554 on it anyway to prevent non-GID-0-members from running it. [just in case] This makes me very happy that I'm not addicted to "bleeding edge everything".
a simple 'right now' fix could deny users NOT in the appropriate login group from running the thing. Some re-assignments via chmod and chown would do that, yeah. Maybe create a new 'xorg' group if one does not exist, assign that to the 'Xorg' binary, and anything else 'suid' that's related to it.
I just checked the 'ports' trees and they've been using 1.18.4 for quite a while now. Looks like FBSD has dodged a bullet by NOT being "bleeding edge" on the X server.
"systemctl stop [displaymanager].service
"Where displaymanager is gdm, sddm, etc. Not really that difficult really."
invoke-rc.d [displaymanager] stop
Slightly easier, it's less typing.
If you don't happen to have invoke-rc.d installed.
service [displaymanager] stop
If you have that installed, though for some odd reason it allows systemd units to override sysv init scripts.
Or if you are really pissed off at things -
killall -KILL [displaymanager]
Still no mucking about with run levels. Out of all of these choices, the systemctl variation involves the most typing. That counts as "made it more difficult".
Not sudo. setuid.
X was setuid in every distribution for DECADES. Some of them still are. X itself runs as root no matter who you are in those distributions, then downgrades itself to the user's level.
Here's a shock - apache does the same thing. You have to run as root to enable you to bind to any port number less than 1024 as a server. So apache starts up as root, binds the port, drops privileges, and runs the rest of its life as "www-data" or whoever while holding something that only root could have obtained. X does pretty much the same, or did. There are ways not to, but pretty much X has spent more of its life starting as root than anything else. Same as "ping", I believe. You have to be root to send ICMP messages. So ping is "setuid root", so whoever runs it is actually running it as root. (Things may have changed in recent years, I don't delve into it myself).
Because of that... anyone on those affected distros (i.e. all but the most secure) is running X as root for a period of time. Which wouldn't be a massive problem if it didn't allow you to specify arbitrary files as the log, and then let you control what's logged. Basically, that's using X as a proxy to read/write any file on the filesystem. In this case, it just happens to set a root password by overwriting the password storage file (shadow).
Yes, it's a dumb idea to run as root when it's not necessary. Fact of the matter is, there's almost ALWAYS a point at which it becomes necessary. Windows has a SYSTEM user, Linux still has root. If they weren't required, those accounts wouldn't even exist. (It actually goes back to the micro-kernel argument of old, where you shouldn't need one user able to "join" all those systems, but if you want sufficient performance, you often have little choice without switching between 20 different subsystems and handing off state information 20 times to achieve something basic).
But it's not an incredibly dumb idea so long as you are very careful and drop privileges as soon as you've done the necessary. In this case, the former failed and - while still root - X allows unsanitised user-specified data to be utilised in the name of a filesystem file which it then gains root write access to, and again to allow the user to specify more unsanitised data which can end up in that file.
Your comments re: apache are wide of the mark. Yes apache starts as root if it wants to bind to ports 80 and/or 443 (http, https). But it's certainly not intended to be installed as setuid, and I should be surprised if anyone ships it as such. You - or more usually your systems init scripts - just start it as root.
Bottom line: if there's a commandline option that'll take advantage of root privileges to do something unintended, then you need root privileges to exploit it. So you might as well just do the unintended thing directly.
1) the user has to belong to sudo group. For a single user linux system this should not be a problem, unless one of your alters is a malicious hacker and you don't have security policy that requires separate logins.
2) the /etc/sudoers file has to have NOPASSWD in it.
If you are running Linux and are concerned that you don't have to enter your password then use sudo to change #2 above. If you really don't trust yourself with sudo, then use Windows.
Why does it work, tho?
/xf86Init.c#L907 should cause a fatal error and abort if ran with elevated privileges anyway?
What am I missing here?
Edit: Ah, nevermind, I didn't see the elseif here
"Good heavens, don't they test their shit, where's the QA?"
"Errors like these just don't happen on properly designed systems."
"It's 2018 and you can get admin rights this easily? Puh-leeze!"
"Can I bill them for the extra work this caused me?"
"How do I get a refund? It's clearly not fit for use!"
"MS is over the hill and will be bankrupt in a couple years from now."
"Year of Linux on desktop is 2019, just mark my words!"
"I burned my grandma an Arch Linux CD back in 2005, and without any instructions she hasn't had any problems with her SCSI scanner since. In your face, Bill!"
"But this isn't a Windows bug, and shouldn't be used as part of a religious war"
You're new here, aren't you? ;-)
Some users - some partaking even in this thread - just happen to gravitate towards all MS articles to tell what's wrong with M$ products and how move to FOSS brings peace and harmony.
Windows is a huge commercial product that a single company makes avalanches of money producing & selling. X and Linux are non-commercial creations produced primarily by groups of volunteers spanning the globe and freely available online. By all logic, we should be able to hold Windows to a vastly greater standard of security & reliability than Linux; the fact that we can't is a problem.
Also, you need to update your "stuff Linux people say" list, it's embarrassingly outdated. You might as well include references to Vista and USB 1.0 while you're at it.
"X and Linux are non-commercial creations produced primarily by groups of volunteers spanning the globe and freely available online."
No they are not. They are produced primarily by employees of companies that profit from open source like Red Hat, Intel, IBM etc. https://www.linuxfoundation.org/blog/2016/08/the-top-10-developers-and-companies-contributing-to-the-linux-kernel-in-2015-2016/ Then there are people like academics who may not be paid directly to work on it, but if its linked to their research it is part of their job.
and Xorg is open source meaning ANYONE can contribute, as needed, or re-build it locally with patches applied and NOT have to wait around for some 2.7 Gbyte download and "at our convenienced" forced-up-our-asses update to come along and "fix" it [and maybe break something else, too]
I'll stick with the much-less-frequent-need-for-it open source patch method, thanks.
> Now, if this were a Windows exploit...
Let Microsoft be ripped to confetti by an antitrust lawsuit with the cash stash distributed to various OSS foundations and let Windows be open-sourced.
No talk before that.
Not get off my lawn, I have doge and AKM.
Not one linux machine here - spanning x86. amd64 and arms (more than one flavor of each) - and several distros, requires you to be "sat at the machine" to get sudo or root - If you can get it at the machine, you can get it remotely (there may be a way to turn that off, but I've not seen it). VNC or SSH make it easy from any remote machine if you log in as a user that is an sudoer. That "have to be there" is an utter myth. On the not-raspberry pi distros you do have to know that user's password, but you'd have to know that either way.
Back when the Norse attack map was up and going, you'd see plenty of attacks to just those ports -"for some reason". Also RDP, of course.
There seems to be a slight confusion here between sudo and being at the console.
The Xorg bug discussed here requires you to be logged in AT the console. On my not-yet-updated-for-this-bug Fedora system, there is a pam configuration line (specifically, `auth required pam_console.so` in /etc/pam.d/xserver) that appears to be ensuring that you cannot run an X server unless you have control of one actual console (that's one of those things you get when you hit Ctrl-Alt-F2/F3 etc).
This has absolutely nothing to do with sudo.
(You actually can run this over ssh also, but only if you are *also* logged in at the console, so it comes to the same thing)
If you're on a typical single user system that is running only the GUI and you rarely go to one of the actual ttys for any reason -- probably the only way to affect you is if someone who knows *some* userid and password to your box, *and* has physical access, were to do that Ctrl-Alt-F2 thing, login, and then run this command.
Servers, mostly running headless, likewise -- you'd have to get into the server room, attach a keyboard and mouse, and do this.
All in all, a very big bug, but not terribly scary for most people.
if you have a system where ssh lets anyone log in, an ssh'd user could attempt to start an X server and specify the output file as 'whatever' for the log, and so the vulnerability still applies.
But I think my 'chmod' or 'chmod' + 'chown' + 'xorg group' method (applied to the Xorg binary's permissions) would mitigate that, preventing anyone not authorized to start an X server from starting an X server by not allowing them to execute it.
Yep -- off topic or not, I've seen that "you have to be at the machine - right there" to do rooty stuff statement here too many times, and even if the post I replied to was incorrect about needing sudo vs ability to mess with suid - it's true despite the downvotes I collected for saying it.
It's tiresome and probably gives noobs the idea that if they have physical security they are safe.
We all know that if you don't, you're done, but the opposite isn't true.
I have plenty of single-user systems headed and headless and of course you need root privileges to do the required customization during setup. Many have never had a keyboard or terminal of any sort physically attached, yet you see this "you have to be at the machine" stuff all the time here.
And if you've got root, fooling with permissions is not exactly a problem either.
There are around 20 machines here that give the lie to that statement.
Just tested this on a very up-to-date FreeBSD install.
"The '-logfile' option cannot be used with elevated privileges."
% Xorg -version
X.Org X Server 1.18.4
Release Date: 2016-07-19
X Protocol Version 11, Revision 0
Build Operating System: FreeBSD 12.0-ALPHA8 arm64
Build Date: 07 October 2018 07:35:55AM
It pays to not be at the bleeding edge I guess. (The Xorg executable is setuid but obviously at this back-level version there are sufficient checks for dangerous options.)
Why does the frame buffer, gpu and mouse need root access and the inevitable setuid root nonsense with its security issues? System V Unix had special devices such as modems that could be opened by one user at a time that didn't require root access. That is why modern systems have /dev/tty* and /dev/cu* which talk to the same hardware but one only allows on user to open it without root privileges.
Given that this flaw is not specific to Linux, and assuming that X.org on Linux and on OpenBSD is exactly the same (same source code), there must be some kind of common understanding between *nix's on this point.
Arguably, if my assumption is correct, this problem shows that that agreement that was reached between *nix's is misguided, and could probably do with some rethinking.
Presumably what's happened is that some additional functionality was added to X.org's command line processing, and the X.org team never considered that what they were adding mattered. After all, they're not the ones putting distributions together, and no one can expect them to keep a close eye on the myriad different installations of their software to see if anyone does something as crazy as giving it setuid root. Rather, it's the distro maintainers who have, not surprisingly perhaps, not been paying attention.
Which highlights the point that whilst a Linux installation or OpenBSD might be bang up to date with the latest and most secure versions of everything (kernel, userland), that can all be blown away by devolving responsibility for how all that is assembled into a distro to a bunch of people who clearly aren't doing their users every possible favour.
Arguably this situation, due to a lack of clear communication and cross-team working, is more likely to arise in projects formed from disparate teams with no starkly underlined mutual interest in self preservation, and less likely in a project from a single team whose employment depends in part on not getting stuff like this wrong. There's no one in the open source world who can sit above all the projects and command them to coordinate properly. So they don't always do that.
Personally speaking I'd no idea that X.org was sometimes configured with the setuid bit set. For something as massive as X.org to have that sounds terrifyingly dangerous! Never mind this trivial escalation through its command line interface, what about other flaws in its implementation. There's a whole ton of code there within which a few nasty surprises could be lurking.
"Why does the frame buffer, gpu and mouse need root access and the inevitable setuid root nonsense with its security issues?"
kernel drivers and devices, for one. You may not want anyone and his brother to be able to accidentally screw with these. An 'suid' application could do so safely, with root-only access to the named devices in the '/dev' tree (as one example). And '/dev/mem' may be involved (another example). so yeah, might wanna 'suid root' on the executable, then make it safe to do so as part of that.
To put this in another way: if your closed-source NVidia driver decides it needs access to /dev/mem (aka the entire system memory), then there is little choice as to have xserver start up as root.
Some drivers are better behaved (the open source ones, typically) but in general startup as root is unfortunately a requirement.
On Twitter. Now anyone who wants to be a nuisance - from bored kids upwards - knows how to do it and will probably try.
Responsible disclosure is making sure those who can fix the problem find out about it while avoiding irresponsible and malicious actors finding out about it until it's been fixed.
The CVE was raised back in July
Raised doesn't mean made public.
I monitor CVEs for a living (it's tedious and boring: since early 2017 there has been a huge increase in ones of no relevance). The first I saw of it was this tweet, yesterday at 9:30 pm.
The NIST site says published on the 25th, too.
Nobody at OpenBSD was made aware of the bug until very late on, despite an OpenBSD developer being on the X security team. The release of 6.4 could have been delayed until after the public annoucement.
The latter can be used to overwrite the shadow password file on a computer to allow access to the root user without a password.
Pfft. Back in the day, you'd use these suid-logfile bugs (and there have been many) to overwrite or create a /.rhosts containing "+ +".1 Overwriting the shadow file was considered unsubtle, if not outright gauche; and .rhosts tolerates random junk better than many other sensitive files.
Of course now that the r-commands have mostly faded into well-deserved obscurity, hacking .rhosts is somewhat less useful.
The real point, of course, is that suid programs that create files in arbitrary locations has long been known as an attack vector. That's one reason why ld.so ignores LD_DEBUG_OUTPUT when running an suid binary, for example. (For a while now it's ignored LD_DEBUG when running an suid binary, making this somewhat irrelevant, but there was a time when the former was suppressed but the latter allowed.)
1This was before people started moving root's home directory to somewhere other than /.
...and this sort of thing here isn't making me feel better.
There's just something about the thing that seems so fundamentally weird that I've never been able to feel good about it. I'm sure there are far smarter people than me who know a lot more about why X is the way that it is who could explain that honestly it all makes perfect sense.
I tried my Ubuntu laptop but it doesn't work. The article mentioned CentOS is also safe. Is this actually as common as the article seems to suggest or is this just a pagefiller about something that only works if your carefully set your system up for intrusion?
Nope. Deb 9 the setuid was removed if current. This breaks startx and Xrdp. So there is now a wrapper. And some config tweaks needed to use vnc. You can run startx against your own console vtxx but it beaks if it auto-allocates, can't write... xorg -query .... aaagh.
This is easy to fix removing he suid bits, but the other tools just need to catch up.
Biting the hand that feeds IT © 1998–2019