LWN: Comments on "An extensive set of X.org vulnerabilities"

An extensive set of X.org vulnerabilities

roskegg — Sat, 20 Jun 2015 23:13:03 +0000

Both those statements are flat out lies.

I didn't claim anything negative about the hotel. In fact, one conference organizer secretly talked to hotel staff and made sure kosher food was available. I am very grateful to him. The conference organizers made claims to me, which made the resort sound like a third rate place. I repeated back to them, "this is what you are describing to me". It was the conference organizers who were misrepresenting the situation.

I didn't hit anyone with the foam club bat. The only time it saw use was near the end; one of the nicer conference organizers was trying to smooth things over, but he did it by repeatedly lying to my face. Not subtle lies, but blatant lies. I held up the bat and told him "You know I have to do this, right?" He nodded, and sat there while I tapped him on the shoulder with the foam. This happened after I'd already been assaulted and the process of eviction had started.

There are a lot of false claims going around about that conference; but I'm not the one making them.

An extensive set of X.org vulnerabilities

Rudd-O — Fri, 19 Dec 2014 12:29:33 +0000

I am so profoundly happy that I made the call to use Qubes OS exclusively.

vulnerabilities during installation & execution

pjm — Mon, 15 Dec 2014 20:57:56 +0000

I think tpo's point wasn't that there's nothing wrong for a user to do "curl | sh", but rather to remind readers that the "make && (maybe sudo) make install" part (or even the "run resulting executable" part) isn't so very different: that your advice of using containers, or at least reading the source, applies in both cases.

An extensive set of X.org vulnerabilities

Wol — Sat, 13 Dec 2014 20:10:41 +0000

> Kinda-sorta. If Wayland really was a newer version of X, it'd be called X12.

Which already exists! (cf a bunch of earlier comments on LWN articles).

Which is why Wayland is X13.

Cheers
Wol

Containing software without annoying users

raven667 — Sat, 13 Dec 2014 15:30:57 +0000

>> The user should not even know that the app is contained; for "normal" apps this is a solved problem.

>And there's the problem. Not everybody has the same notion of a "normal" app. I just don't see how you would do it without either losing tons of flexibility or writing tons of complicated policy.

Just because it can't work transparently for every possible program doesn't mean that it's not a good model to start from, a target to aim for, or that it won't work for the vast majority of desktop software.

>> If the application opens a file using the standard (and trusted) file open dialog, the application gets rights to that file.
> Let's leave aside the fact that there's nothing like a standard file open dialog on my system

Well, that's kind of your problem, you can't always take advantage of the work and standards that others make if you march to the beat of your own drummer, that goes for the app developers too.

> This magic file picker needs to be appropriate for all apps that are going to run inside that session. I just don't see this happen.

The vast majority of apps use a toolkit which provides a comprehensive, flexible, file picker widget. What you really need is negotiation and agreement from the top two or three toolkit developers to add support for file pickers over IPC with a standard policy hook, if this doesn't already exist.

Of course that won't cover all programs but you can hopefully cover the most exposed targets and provide guidance for the rest to come along on their own time. I think you still get significant benefit if you can containerize the top 80 out of 100 of the most used desktop applications, even if there are 10,000 other apps which aren't covered.

> It might work on Android

Yes, you see a bunch of work on this on more modern platforms. The new-type systems like Android , iOS and ChromeOS may replace traditional desktop systems like Windows, MacOS and Linux anyway except maybe for certain kinds of content creation and software development work.

> How would you contain something like Emacs without severely neutering its usefulness?

To contain an app like that there would be constraints which you might consider neutering because while you would be able to do the things you want to do you probably won't be able to negotiate on the _way_ you do them. An example of a constrained file access model might have ~/Documents/Emacs "owned" by emacs and this (along with ~/.config/Emacs and ~/.local/Emacs, maybe a few other settings files) are the only places where it can do unconstrained read/write, every other file access is either read-only or uses an IPC service which validates the request. That would would be a constraint on where you put your source code projects, mail spool, etc. that you expect to be editing, probably necessitating remote source control to get files in and out of the container. You might also make your app require its own private repository of tools rather than having shared tools as part of your OS, so it gets its own /usr with docs and compilers and whatever.

> > But even if there aren't any intentional holes, if your application has one little buffer overflow and parses one slightly odd attachment then suddenly your friendly F/OSS software becomes rather hostile.

> Yes, of course. That's a problem, I agree. I just think the solution is going to be a little harder.

Anyway this kind of containerization is very possible but there are tradeoffs. Concentrating on the programs which are most likely to be exposed, like web browsers, anything that might be spawned as a dependency of viewing an attachment, anything that talks directly over the network, is going to provide the most bang for the buck.

Also comprehensive political and legal reform on how the internet is regulated to try and reduce the base level of hostility in the environment would be a good parallel project to technical security measures. 8-)

Containing software without annoying users

lsl — Sat, 13 Dec 2014 05:26:45 +0000

> The user should not even know that the app is contained; for "normal" apps this is a solved problem.

And there's the problem. Not everybody has the same notion of a "normal" app. I just don't see how you would do it without either losing tons of flexibility or writing tons of complicated policy.

> If the application opens a file using the standard (and trusted) file open dialog, the application gets rights to that file.

Let's leave aside the fact that there's nothing like a standard file open dialog on my system and imagine a system where somehting like that exists and is chosen by the admin or on a per-user-session basis. This magic file picker needs to be appropriate for all apps that are going to run inside that session. I just don't see this happen. What about computed paths or those obtained from the user in some other way? All this would be severely restricting the kind of app you can write (or require much policy-writing effort upfront).

It might work on Android where you have a pretty restricted app model (and app are mostly trivial and don't work much with local files anyway). Or even for big applications that don't interact much with the system. But for the general case on a general-purpose computer?

How would you contain something like Emacs without severely neutering its usefulness?

> But even if there aren't any intentional holes, if your application has one little buffer overflow and parses one slightly odd attachment then suddenly your friendly F/OSS software becomes rather hostile.

Yes, of course. That's a problem, I agree. I just think the solution is going to be a little harder.

Containing software without annoying users

gmatht — Sat, 13 Dec 2014 03:31:41 +0000

The user should not even know that the app is contained; for "normal" apps this is a solved problem. If the application opens a file using the standard (and trusted) file open dialog, the application gets rights to that file. Likewise clicking "paste" or "Control-V" gives the application the right to read the clipboard. There was even an attempt to retrofit this using LD_PRELOAD so that existing GTK software could be so constrained without so much as a recompile. I understand one reason this didn't take off is that due to X's security weaknesses it didn't add much extra security without nested X servers.

There have been cases of software being discretely tampered with. But even if there aren't any intentional holes, if your application has one little buffer overflow and parses one slightly odd attachment then suddenly your friendly F/OSS software becomes rather hostile.

An extensive set of X.org vulnerabilities

thestinger — Fri, 12 Dec 2014 07:40:36 +0000

Running stuff as nobody is not a good approach to securing a system. For example, one process running as nobody can ptrace (i.e. debug, just like gdb) another so it falls apart as soon as it's used for more than one process. It also impacts files, temporary files and some forms of IPC - not just the ability to ptrace.

This is prevented by grsecurity's ptrace feature or Yama's ptrace_scope (based on the latter) but they are not always enabled. They're fairly impractical on a machine used for software development (no strace -p, gdb -p, etc. without admin capabilities).

It would make sense to sandbox it (via seccomp, namespaces and chroot) but it's not going to accomplish much since as you pointed out it has access to all of the rendered frames for GUI apps + lots more.

An extensive set of X.org vulnerabilities

nybble41 — Fri, 12 Dec 2014 05:51:41 +0000

> If they get root, they can also install printer drivers.

If they get root, they can also install a rootkit. Which means that you can't even tell that they've infiltrated your PC. Which means that you don't know that they have your data, and that they can lurk in the background and collect new data as it's entered and/or use your PC as a base to infect other systems.

At least while the malware is limited to your unprivileged account you can see it with ordinary diagnostic tools and have a chance at removing it. If it gets root the only way to get back a clean PC is to wipe everything and restore from backup—and even the backups are suspect.

This is not to say that non-root malware is insignificant, just that there is good reason for giving the root account special consideration, even on single-user systems.

An extensive set of X.org vulnerabilities

josh — Thu, 11 Dec 2014 22:27:56 +0000

I agree with you; once an attacker has a local account, even an unprivileged one, you've lost. However, unless you have TCP turned on (which you shouldn't), all of these X vulnerabilities only provide local exploits, not remote exploits. And running X as the same user running the apps connecting to it means those local exploits don't actually gain any privilege.

An extensive set of X.org vulnerabilities

jwarnica — Thu, 11 Dec 2014 21:49:50 +0000

If they get my account, they get all the data I care about. And mine bitcoins, spam whomever. Whatever.

If they get root, they can also install printer drivers.

La-de-dah.

An extensive set of X.org vulnerabilities

mathstuf — Thu, 11 Dec 2014 19:39:17 +0000

It would be interesting to have a tool which I could shim in between the real X server and a client that would implement XACE and/or XSELinux so that I can test applications with the restrictions. ISTR an application which would do so for logging at least.

An extensive set of X.org vulnerabilities

dpquigl — Thu, 11 Dec 2014 17:05:40 +0000

XACE and the SELinux module are there to solve a different purpose than simple application sandboxing. There are people who use it and they use it to implement systems similar to older Compartmented Mode Workstations (CMWs). I use to work with the XACE guy and the demos he had were for information flow control. He had a demo that used the MLS components of an SELinux context to prevent copy and paste between editors of different levels. The problem and reason why we don't use it in Fedora is that X11 and the applications and frameworks that run on top of it aren't built to handle this extra security. They make many assumptions about access to information via the X protocol and die horribly in a fire if they don't get access to it. Many of the applications tested would just crash and exit because they weren't written to assume certain calls can fail which was not the case with the new access control framework.

An extensive set of X.org vulnerabilities

nix — Thu, 11 Dec 2014 16:45:04 +0000

Quite possibly they are sincere positions. However, sincerely being a sexist conspiracy theorist loon still doesn't reflect well on him.

An extensive set of X.org vulnerabilities

ortalo — Thu, 11 Dec 2014 16:27:43 +0000

Whatever your gratitude, IMHO, that may be what they try to do first.

What you may like much less is that they are usually succeeding in elevating privileges and subsquently use them to protect their illegitimate access (from competiting attackers) and/or to attack other victims - leaving you as the apparent culprit. Admittedly they do not need to be root for the last part but it may help them relay their attacks longer and more easily.
Attackers will only loot your bank account when everything *else* is over.

An extensive set of X.org vulnerabilities

lsl — Thu, 11 Dec 2014 14:50:13 +0000

> Wow, sizeist, too. Jonathan, worthiness correlates no better with national origin or physical stature than it does with sex, skin color, dental configuration, hair details, shoe size, personal wealth, or favorite color.

I read that last bit as "favorite editor" first and already wanted to protest vehemently. After double-checking, though, there's nothing left to object to, so I can only agree 100 % with the above.

An extensive set of X.org vulnerabilities

lsl — Thu, 11 Dec 2014 14:38:19 +0000

It pretty much works out-of-the-box on Arch Linux. That is, as long as you're starting X via startx. Don't know what's the state with the various display managers.

https://www.archlinux.org/news/xorg-server-116-is-now-ava...

An extensive set of X.org vulnerabilities

mathstuf — Thu, 11 Dec 2014 03:52:23 +0000

You missed the rest of the sentence:

> where the script there contains a 'sudo' (some go so far as to pipe to 'sudo sh').

Hiding sudo behind a shell script you want be to blindly pipe to a shell is stupid no matter what.

I don't like the practice to begin with because at least with download/make/make install there is an inspection period (unless you find a code execution bug in tar or something). Personally, I configure all software to be installed into individual roots the select the roots depending on what is required. What I really need is a sandbox which blocks the tools from writing anywhere other than the source/build tree during the build and the build/install tree during install. I imagine SELinux could probably help here, but my knowledge of how to approach the problem there is close to nil right now.

An extensive set of X.org vulnerabilities

daniels — Thu, 11 Dec 2014 01:57:12 +0000

Kinda-sorta. If Wayland really was a newer version of X, it'd be called X12. It makes a number of radically different design decisions (ones which I'd argue are improvements, mind), so it'd be unfair to call it X12. Much like calling Linux, Minix 2.

An extensive set of X.org vulnerabilities

ncm — Thu, 11 Dec 2014 00:23:20 +0000

Wow, sizeist, too. Jonathan, worthiness correlates no better with national origin or physical stature than it does with sex, skin color, dental configuration, hair details, shoe size, personal wealth, or favorite color.

*BLOCKED*

An extensive set of X.org vulnerabilities

tpo — Wed, 10 Dec 2014 23:16:37 +0000

> What we really need to stop is shit like this:
>
> $ curl https://install.meteor.com | /bin/sh

I do not understand, how that is much different from:

right-click somwhere->Save

$ tar xzvf some_stuff_downloaded_from_somewhere.tgz
$ cd some_stuff_downloaded_from_somewhere/
$ make
$ (maybe: sudo) make install

Often enough I do these things in /tmp anyway, especally for stuff I'm updating. So it wouldn't survive the next reboot in case I'd need to analyze something after the fact.

What is the fundamental difference then to the "traditional" Unix way of installing fresh stuff?

I am aware that going the full length of verifying checksums and making educated plausibility checks based on that might be a bit better. However that is not the standard way of making sources available today and has been much less so in the olden days.

So I really still don't understand much.
*t

An extensive set of X.org vulnerabilities

sjj — Wed, 10 Dec 2014 21:59:27 +0000

Yes, this is an execrable anti-pattern. RVM does it too and they only just last month (!) added release signing...

An extensive set of X.org vulnerabilities

vonbrand — Wed, 10 Dec 2014 21:55:09 +0000

Never forget Hanlon's razor...

An extensive set of X.org vulnerabilities

josh — Wed, 10 Dec 2014 21:46:47 +0000

All of these X server compromises require that you have a connection to the X server. Assuming the server doesn't listen via TCP, and it runs as a user with access only for that user, then only that user can compromise it, and they'd only get the same permissions they already have. It wouldn't be a privilege *escalation*, the way a user exploit of an X server running as root would be.

An extensive set of X.org vulnerabilities

mathstuf — Wed, 10 Dec 2014 21:44:15 +0000

Well, I did say "maybe". Yes, that certainly seems useful (and isn't something I do often, so hadn't come to mind).

An extensive set of X.org vulnerabilities

viro — Wed, 10 Dec 2014 21:41:07 +0000

Congratulations, you've just broken !!sh<enter> in vi. I.e. something I'm using all the time - shell commands composed in editor, piped to shell and replaced with their output. And I suspect that emacs folks also won't thank you for that. It's a fairly common workflow.

An extensive set of X.org vulnerabilities

raven667 — Wed, 10 Dec 2014 21:25:41 +0000

If anything, the rewrite to fix fundamental security problems with X11 is called Wayland (X13 in all but name)

An extensive set of X.org vulnerabilities

mathstuf — Wed, 10 Dec 2014 21:23:37 +0000

Oh, indeed. I missed the detail section and saw "Install Fedora 21" in the "How To Test" section. Probably needs updating then :) .

An extensive set of X.org vulnerabilities

mathstuf — Wed, 10 Dec 2014 21:17:16 +0000

What we really need to stop is shit like this:

> curl https://install.meteor.com | /bin/sh

where the script there contains a 'sudo' (some go so far as to pipe to 'sudo sh'). Maybe sh should just refuse to listen to stdin that isn't a TTY without a script as an argument. Either way, this being your "install instructions" for *developers* to use your framework is 100% unacceptable.

An extensive set of X.org vulnerabilities

rahulsundaram — Wed, 10 Dec 2014 21:16:44 +0000

That's scheduled for Fedora 22. Not Fedora 21.

An extensive set of X.org vulnerabilities

da4089 — Wed, 10 Dec 2014 21:14:26 +0000

Let's see: My Account, Edit Filtering, roskegg, Ok. Ahhh, that's better.

An extensive set of X.org vulnerabilities

mathstuf — Wed, 10 Dec 2014 21:13:03 +0000

I haven't set it up for my 'startx' workflow yet, but Fedora 21 shouldn't have a root X server if you're using a typical DE:

https://fedoraproject.org/wiki/Changes/XorgWithoutRootRights

An extensive set of X.org vulnerabilities

nwnk — Wed, 10 Dec 2014 21:03:38 +0000

That is what I mean, though it's spelled XACE now. The extension isn't enabled by default, but it's there if you want it. Admittedly I don't know where one would go to acquire a reasonable "default" policy for it; if someone wanted to write one, I'd happily ship it.

Sandboxing isn't necessarily better or worse. You get pretty solid isolation from the host X server, but that cuts both ways: XDND actions won't work, you don't get accelerated 3D (yet), etc. If all you want to do is isolate an app away from the containing X server's (elevated) privilege level, then sandboxing will do just fine. If you need actual MLS in one X display then XACE is the better mechanism.

But even there, X.org has actively enabled both the XACE and sandbox models. The selinux sandbox tool uses Xephyr, which wasn't a thing in XFree86, and we've taken patches to make Xephyr usable for the sandbox use case (initial window placement, resizable window, window title proxy, etc). If the assertion is that X.org has made no effort to improve X's security (as sir roskegg seemed to be claiming) then I really don't think the claim stands up to the evidence.

An extensive set of X.org vulnerabilities

sjj — Wed, 10 Dec 2014 20:54:02 +0000

You're both right, I think.

I think I'm getting to the point where Qubes is very very interesting. It gives you isolation and configurability, granted at the cost of some convenience and hardware (vt-d and enough memory).

An extensive set of X.org vulnerabilities

sjj — Wed, 10 Dec 2014 20:48:11 +0000

I'm just waiting for an attack that will exfiltrate $HOME/{.ssh/*|.gnupg/|.*history|.aws/*|.boto} etc using a popular Rubygem or Github-hosted script (just as an example).

You hit a bunch of developers and sysadmins with that and you've got access to some serious infrastructure.

An extensive set of X.org vulnerabilities

sjj — Wed, 10 Dec 2014 20:38:48 +0000

Got links?

An extensive set of X.org vulnerabilities

sjj — Wed, 10 Dec 2014 20:37:34 +0000

You mean XSELinux? Is it used by anybody? According to SElinux wiki, even Fedora doesn't enable it. Instead you're supposed to use manual sandboxes.

An extensive set of X.org vulnerabilities

dlang — Wed, 10 Dec 2014 20:02:04 +0000

a secure system that doesn't do what the users need to do is worthless.

Users need to be able to use the same data files with multiple apps. Granting access where it's needed and wanted without granting access where it's not (or where it's dangerous) is not a solvable problem.

An extensive set of X.org vulnerabilities

HelloWorld — Wed, 10 Dec 2014 19:58:44 +0000

No, you're utterly wrong. Compartmentalizing things is the only way to ever get a reasonably secure system. And this has nothing at all to do with whether the programs are open source or not.

obligatory XKCD:

HelloWorld — Wed, 10 Dec 2014 19:46:55 +0000

http://xkcd.com/1200/