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

So similar risk to accidentially typing 'sudo'

[Anonymous Coward]

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'

[buchanmilne]

"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:So similar risk to accidentially typing 'sudo'

[Tough Love]

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 the exploit is only possible if the X server (Xorg) is running suid.

Please correct me if there are any distros out there installing Xorg as suid. I doubt that there are.

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.

Re:So similar risk to accidentially typing 'sudo'

[Tough Love]

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'

[Type44Q]

You will be asked for a password

They accidentally entered that, too.

If this is a vulnerability; my programs have a lot

[orlanz]

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: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.

Still dependent on X after all these years.

[xack]

Xouvert, Wayland, Y, DirectFB, SVGAlib, Fbdev, Mir, NeWS and so many others have failed to break the X curse on Linux.

Re:Still dependent on X after all these years.

[Fly Swatter]

Good ol' X, often berated, never surpassed. Kind of means they got it right all along.

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:Still dependent on X after all these years.

[SigmundFloyd]

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.

Me neither, but they would need to make it usable over WiFi. And do it 15 years ago.

And they had better keep things like middle-click paste.

But also fix the horrible mess that inter-application copy & paste is on X11. The Mac got it perfectly right in 1984.

Re:Still dependent on X after all these years.

[serviscope_minor]

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 remotely common.

In 3 the data types agree a mix of mime types these days and usually a few old X yours like TEXT.

In 4 there's no indication of the owner has preferred type.

5 is a little messy of the data is large since the connecting is remote and so it has to be cut into chunks and sent one at a time.

So what's wrong with that?

Re:Still dependent on X after all these years.

[Uecker]

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 explain exactly how you think this could be the case.

Re:Still dependent on X after all these years.

[Anonymous Coward]

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 application you had, select whatever you wanted to copy, go back to the other thing and finally paste it.

Re:Still dependent on X after all these years.

[serviscope_minor]

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. Control only happened when the usual suspects insisted everything had to be like Windows to win. We can see how well that worked, but that's ancient history. Some other very old programs from the days of yore also didn't do the clipboard thing properly, but I've not encountered one of those in maybe 15 years now.

Re:Still dependent on X after all these years.

[caseih]

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?... . 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:Still dependent on X after all these years.

[Uecker]

Yeah, right... Daniel Stone of Wayland is the only one understanding X.

Re:I thought Linux was the bastion of security

[Anonymous Coward]

For starters, it doesn't ship your data to India or erase it

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:Privilege escalation unlikely

[Antique Geekmeister]

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:Privilege escalation unlikely

[Guybrush_T]

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:Privilege escalation unlikely

[alexhs]

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 the chmod workaround doesn't prevent that issue -- actually the chmod command doesn't even work if you're not root).

Re:Privilege escalation unlikely

[alexhs]

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 dangerous, it makes sort of sense to have the setuid bit on the binary on a system not starting an X session on startup, so that a user can start a session later. If Xorg follows basic security practices, it drops the privileges after the program initialization to minimize the attack surface, but the bug here happens early, so it's still vulnerable.

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.

Re:Privilege escalation unlikely

[nawcom]

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:Privilege escalation unlikely

[alexhs]

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:

/usr/lib/xorg/Xorg.wrap: Only console users are allowed to run the X server

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:Privilege escalation unlikely

[Swave An deBwoner]

From TFA:

Leveraging it after gaining access to a vulnerable machine is fairly easy. Matthew Hickey, co-founder, and head of Hacker House security outfit created and published an exploit, saying that it can be triggered from a remote SSH session.

Re:Privilege escalation unlikely

[Tough Love]

From the man page "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 in jessie, stretch and sid, but not yet in buster.

Re:Privilege escalation unlikely

[pi_rules]

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.

Re:Privilege escalation unlikely

[Swave An deBwoner]

Some folks require remote (SSH) access to their workstation which unsurprisingly usually has an X server installed.

Re:Privilege escalation unlikely

[Swave An deBwoner]

Your comment is confusing to me

Do you understand that I was responding to the statement quoted below?

.Only if the sysadmin is a complete moron and has an X server running on a server with remote users.

Re:Where is Wayland

[bill_mcgonigle]

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:If this is a vulnerability; my programs have a

[Antique Geekmeister]

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.

That's not what "trivial" means

[chispito]

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.

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:If this is a vulnerability; my programs have a

[Narcocide]

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:If this is a vulnerability; my programs have a

[jmccue]

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.

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

[Anonymous Coward]

Not surprised the terminology is backwards. The majority of Open Sores stuff is incredibly ass backwards

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

[Waffle Iron]

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".

Re: I thought Linux was the bastion of security

[Anonymous Coward]

Thread over. rootless X has been around longer than this bug

OpenBSD syspatch already available

[psergiu]

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.

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

[Cmdln Daco]

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:Where is Wayland

[kbrannen]

There are still some real issues Wayland has yet to fix and until they do, there is a large enough fraction of users who won't use it. For me, the killer missing feature is remote usage, which X11 does a good job of. I've heard XWayland is supposed to be the answer for that, but it's apparently not fully baked yet. I won't give Wayland the time of day until it can do this feature ... I don't use it every day, but I use it multiple times a week so it's a very real use case for me and others.

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 disagree. X11 has its problems, but it's still plenty good and many of rely on it daily (using it right now in fact). It does everything I need so I don't see a big need to change. I'm sure others care more because they have different needs.

That being said, I'm trying to keep an open mind about Wayland to see what it's really like when it finally becomes mature enough; but I don't believe I truly need it so I'm not anticipating it and it can come when it's good and ready.

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

[Waffle Iron]

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:If this is a vulnerability; my programs have a

[toadlife]

...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

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

[Anonymous Coward]

It's not 'stupid' just because you mistakenly think you know what it means.

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

[buchanmilne]

"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:Where is Wayland

[ArchieBunker]

I must know, what is everyone doing remotely that they need X?

Re:Where is Wayland

[serviscope_minor]

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.

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).

Then my Sgi/Octane has some workload for today

[ReneR]

recompiling the X.org server in #t2sde Linux; https://www.youtube.com/watch?... ;-)

Re:Where is Wayland

[Uecker]

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.

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: If this is a vulnerability; my programs have a

[aliquis]

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: If this is a vulnerability; my programs have

[schure]

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.

different pastes

[unixisc]

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

Re:different pastes

[serviscope_minor]

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:different pastes

[unixisc]

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 version 3. I just wish the GNUSTEP people would step up to make something that both Linux and the BSDs could use OOTB

Re:different pastes

[serviscope_minor]

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 terms of what I pasted an hour ago.

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

[ClickOnThis]

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.

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

[ClickOnThis]

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.

Printer in Error State

[Florida wilson]

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.