The Linux Security Circus: On GUI isolation

http://theinvisiblethings.blogspot.fr/2011/04/linux-security-circus-on-gui-isolation.html

by simonbrown • 12 years ago

148 68 12 years ago

theinvisiblethings.blogspot.fr

ecma2• 12 years ago

Interesting that this comes up again with Ubuntu Trusty continuing to retain Xorg. Is anyone familiar enough with Mir and Wayland to comment on how those packages approach this kind of thing?

htns• 12 years ago

Both fix it by making snooping and spoofing unavailable by default. An application only has access to its own windows, inasmuch processes are properly isolated in other aspects as well. Typically they aren't, e.g. very few distros have any "single user level" safeguards for ~/.bashrc. Qubes solves that problem as well.

flogic• 12 years ago

Does it actually matter? For the average desktop, everything of monetary value will be under the main user account. Which is generally also the account used to touch the internet.

ecma2• 12 years ago

I think it does matter. Defence is relevant at almost every level of software. If a window manager can make smart design choices to make it non-trivial to implement bad software for the interfaces it serves, it's an obvious choice IMO.

XorNot• 12 years ago

This is a problem which needs to be fixed, as cryptolocker demonstrates.

We really need some hard boundaries set between non-interactive and interactive requests to open files.

Sensible ones too - not "ask about every file", but maybe "grant process access to this folder in my documents folder, without recursive access".

Even better would be "fire this backup utility first, then grant access".

carver• 12 years ago

Yikes! Yet another reason to use paper bitcoin wallets.

simondedalus3• 12 years ago

i've been saying for awhile now (to anyone bored enough to listen) that qubes style isolation is the only safe idea on offer these days. i just wish qubes were usable.

i'm fairly sure that 10 years from now people are going to be citing joanna rutkowska articles with regularity. her flatfooted denial that security is possible without isolation is the only sane perspective.

the point is that starting from full isolation and straining to get things to talk to each other in the hope of achieving productivity makes sense. starting from full interactivity and straining to isolate but just when it's necessary "for security" is a battle we will all eventually lose, and we should know it already.

anaphor• 12 years ago

Doesn't djb espouse a similar viewpoint wrt sandboxing? Not to say she doesn't have any original ideas for how to achieve it, but it's hardly a novel concept.

simondedalus3• 12 years ago

yes.

i'm not saying the concept is novel, i'm saying that it's the only viable option for the systems of today. related to that, i think the qubes approach will be adopted eventually (and that articles of hers, specifically, that i've read will likely come into fashion, despite the--dare i say it--borderline sexist reaction many on hn seem to have to "her tone").

regarding outright original thought, i'm sure both she and he are guilty of it. probably you and i as well; it's easier than a lot of people think. the world is large and complex, and really most of the "oh my god i can't believe [person] thought of [amazing idea]!" really ought to be marveling at the fact that [person] implemented [amazing idea] as a practical tool.

sure, we rehash over and over in our thought, but the world of ideas is so specialized that given even a few months of serious study, novelty is not particularly impressive.

zobzu• 12 years ago

SELinux has xorg hooks [1] to isolate the gui, actually... yes that means with SELinux you can control which window can talk to which, what clipboard can be used where, by what window, etc.

not that it makes the xorg code better in any way, but, when you're going to say the world is ignorant and you know it all, at least get your stuff right.

Thats why people "hate" you as you describe in this post. Having an aggressive style doesn't make you more accurate. It just makes you annoying.

[1] http://www.nsa.gov/research/_files/selinux/papers/xorg07-pap...

roghummal• 12 years ago

This is the kind of hyberbole you get when someone is trying hard to maintain a high profile when their 15 minutes is over.

It doesn't matter if you're right, wrong, or even interesting as long as you get the page views. Blech.

long• 12 years ago

She is aware of this but has a bone to pick with the particular way that SE Linux secures the GUI: http://theinvisiblethings.blogspot.com/2011/04/linux-securit...

I agree, though, that the style is overly aggressive.

ris2• 12 years ago

I particularly disagree with her assertion that Xen is a more trustworthy place for security over the "big, bloated linux kernel". I would argue that the (perhaps smaller) Xen code has seen far less security scrutiny than the kernel and has a far less pronounced culture of security.

schoen• 12 years ago

I agree with the concern and appreciate the solution that Qubes offers.

It might be worth pointing out that some of the "hippies" also became concerned with this and implemented their own partial solution within the X framework decades ago -- the "secure keyboard" feature. You can see it in action: run an xterm, Ctrl-Left Click in the window, and choose "Secure Keyboard" from the menu. Now all X11 keyboard events are sent exclusively to that xterm, not to any other X application (even if the other application has focus). Caution: for these purposes the window manager is also an "application", so you won't even be able to Alt-Tab to switch applications while the secure keyboard mode is active!

The X11 developers assumed that you would use the Secure Keyboard feature while typing important passwords. There's a pretty elaborate discussion of this in the man page for xterm(1).

There, the threat that they're most focused on is remote display access from applications on other hosts, rather than malicious software potentially running on the local host. For example, the authors of xterm fear that you'll be using machines foo and bar in the same computer lab, and run "xhost foo" on bar, and then an attacker will rsh into foo and log in to their account there and then run "DISPLAY=bar:0 keyboard_sniffer" from their account on foo, whereupon the X server on bar will conclude that the remote client request from foo is perfectly legitimate because you told it to accept all X11 connections originating from foo.

Of course the secure keyboard feature only partially mitigates one aspect of this threat, while Qubes offers a much more thoroughgoing and useful mitigation to a larger range of things. (I might also mention ptrace, where recent Linux distributions have activated a kernel policy which forbids, by default, having a non-root process start to ptrace another running process that isn't its child. I believe this was in response to malware grabbing private keys from programs like ssh-agent via the ptrace interface. Oops. It does also mean that you can't strace -p or gdb attach something that's already running, unless you become root and change the policy.)

In general, the idea of protecting against software that's running locally as the same user is something of a novelty on most desktop OSes.

https://en.wikipedia.org/wiki/Discretionary_access_control

Someone• 12 years ago

We also have http://www.cs.dartmouth.edu/~doug/IX/, in particular "Multilevel Windows on a Single-Level Terminal" (http://www.cs.dartmouth.edu/~doug/IX/163f.ps):

"The workings of mux, a windowed-terminal handler, that can run differently classified sessions in different windows."

[google search tip for historians/computer archeologists who don't want to find SE-Linux when searching for Unix history: enter "before 1/1/{years ago} as a custom time range]

lmz• 12 years ago

I hear Solaris has Trusted Extensions for X11 (e.g. [1]). Would that handle this case better?

[1] http://www.desktopsummit.org/sites/www.desktopsummit.org/fil...

emmelaich• 12 years ago

Possibly; but without being familiar with TX, I would like to point that Oracle are enhancing Solaris TX with _Flask_, which essentially IS SELinux.

ciupicri• 12 years ago

The title should have (2011) at the end.

bm98• 12 years ago

The very first comment below the article (correctly) contradicts the author's claims about SELINUX sandbox. The author acknowledges the comment, and criticizes the SELINUX implementation, but does not dispute the fact that SELINUX sandbox ("sandbox -X xterm" in RHEL/CentOS/Fedora/SL) does in fact defeat the keystroke logger attack described in the article.

reidrac• 12 years ago

I would be nice if the article was amended to acknowledge the fact that a SELinux sandbox actually avoids "the problem".

I'm being confused with the "you will likely need to install it first: yum install xorg-x11-apps"; which means you need extra privileges before implementing the attack "as normal user!".

I guess the problem is not local access but a malicious app perhaps, but then it doesn't matter too much anyway because there are other ways of compromising the system.

koios• 12 years ago

The yum install xorg-x11-apps bit is so you can use the xinput tool as a demonstration of the problem. Fedora doesn't have it by default apparently so you need to install it.

A malicious app could just directly use the X protocol, no need to call this app, so unfortunately no additional privileges are needed.

puzzlingcaptcha• 12 years ago

Apparently you don't need to execute it with elevated privileges so you can build it (or your own variant) statically on a different machine for all you care.

xenophonf2• 12 years ago

"I guess the problem is not local access but a malicious app perhaps, but then it doesn't matter too much anyway because there are other ways of compromising the system."

Well, that's the idea - protect a user from malicious apps running within their security context. Qubes does this by running apps within their own virtual machines.

chris_wot• 12 years ago

What did she mean by "The primary problem with SELinux sandbox is that it still relies on the big, buggy, bloated Linux kernel to enforce security."

Genuinely curious.

eliteraspberrie• 12 years ago

BTW, Windows is the only one mainstream OS I'm aware of, that actually attempts to implement some form of GUI-level isolation, starting from Windows Vista.

Is GetAsyncKeyState still available in Windows Vista? I'm guessing it is, and processes can still read each others' keystrokes without problem. The MSDN documentation doesn't mention it being deprecated. http://msdn.microsoft.com/en-us/library/windows/desktop/ms64...

(By the way this article is from 2011. It would be interesting to read an update.)

lucb1e• 12 years ago

Perhaps it needs admin permissions (UAC) though?

That would be the same as running it as root, so in that case it would make sense that you can listen to get every keypress. If not... then yep Windows Vista is as much a 'security circus' as anything else.

ef47d35620c1• 12 years ago

Yes. Here's a Windows keystroke logger (with source code) that uses GetAsyncKeyState. I wrote this years ago to show an IT auditor that a restricted user could run a keystroke logger (he was adamant that was not possible). It works on Windows XP to Windows 8.

http://16s.us/software/16k/

CyberShadow• 12 years ago

GetAsyncKeyState will not reflect input that is sent to an elevated window. So, it does not break UIPI.

aktau• 12 years ago

Oh man! I only wrote one program ever that could be used for malicious intent if so desired, and that was a GetAsyncKeyState()-based keylogger. Simple to write and so cool. The toughest part was figuring out how to register itself as a windows service and give it a good name so most people would ignore it. I ended up making a separate executable for that.

Anyway, I got curious to see how my coding style had evolved since I was a kid so I dug it up for all to see: https://gist.github.com/aktau/11057438 (I was young, be gentle).

atesti• 12 years ago

The download of the exe file gives an error message, the cpp and txt files are fine though.

rnnr• 12 years ago

If they run on a different SessionID you won't be able to log anything. This means you want be able to log what other users type.

The article is becoming somewhat obsolete now with all the new windows/apple store apps though. (I m not talking about their store aspect)

rcxdude• 12 years ago

I'm guessing she's referring to the UAC dialog (I wonder if it also applies to apps run via UAC).

ams6110• 12 years ago

In the 1990s I worked at an investment bank, all the developers had X terminals (these were workstations that just ran X servers, they did not have any other local compute or storage resources). I discovered one day that I could run a program and direct the display to any X terminal in the network. There were some screensaver-type programs that would make everything on your screen a mirror image, or appear to melt down and run off the bottom of the screen. It made for some fun pranks.

SixSigma• 12 years ago

That is by design and is the default, it is specifically mentioned as an issue in the first paragraph on the manpage http://www.x.org/archive/X11R6.8.1/doc/Xsecurity.7.html

joveian• 12 years ago

For a lot of end user systems it doesn't really matter if cross-user protection boundaries exist or not because there is only one user on the system. It is the lack of sub-user protection boundaries that is a big concern.

I hadn't heard of Qubes, looks interesting.

ape42• 12 years ago

I agree if I launch app A and I launch app B its ok if they can see what the other is doing. But what if some nasty process launches an app. Of course, viruses (etc) are very rare on Linux.

antocv3• 12 years ago

It is of concern when user browses badsite.ir and flash runs some process as the user.

microcolonel2• 12 years ago

Glad to see this reposted(although it being this specific article is of no particular value, there are other articles on this which don't have such shameless plugs).

We now have Wayland well on its way to replacing X(I'd say within two to three years, some users won't ever know they're running Wayland), and from what I can tell, it will offer fairly good isolation for input.

Another important step is graphics drivers being cleaned up to improve isolation between graphical clients. For the time being, though, I can create a GL context and not draw anything, but still see parts of the framebuffer in my context, which I find giggle-worthy.

I think the basic problem here is that graphics systems are hard enough to make work at all, let alone make secure. I will probably not trust a system this complex to protect input or content for a long time, if ever.

sparkie• 12 years ago

Blogging about a problem and giving your solution is not a shameless plug. What would you prefer, an article which describes a bunch of security problems and doesn't tell you how they can be resolved?

shmerl• 12 years ago

It's an old post, but it applies to X.org all the same. Wasn't Wayland planning on addressing these issues?

ape42• 12 years ago

Here's some guy getting xeyes working on Wayland. http://blogs.gnome.org/wjjt/2012/03/14/looking-around-waylan...

EmanueleAina• 12 years ago

That proof-of-concept relied on a custom protocol extension which, as the author pointed out, was not meant to be merged in Wayland/Weston. In any case the extension required application to ask the compositor to be notified of the pointer position even when not "owning" it and the compositor can flatly refuse it to non-privileged clients according to any policy it wants, which is quite different from the current X11 situation.

This article has some useful information on how Wayland addresses the security concerns expressed in this thread: http://mupuf.org/blog/2014/02/19/wayland-compositors-why-and...

edwintorok• 12 years ago

Here's a summary of security in Wayland: http://mupuf.org/blog/2014/02/19/wayland-compositors-why-and... https://lwn.net/Articles/589147/

mdwrigh2• 12 years ago

Well, if you count Android as mainstream OS then it too has GUI isolation. One app can't receive key events when another has focus, nor can it inject events into other applications.

okasaki2• 12 years ago

People bring this up sometimes, but I've never heard of this being used in any real attack/malware. It appears to be a purely theoretical threat.

politician• 12 years ago

Broad-spectrum attacks on our global information infrastructure appeared to be purely theoretical until Snowden published.

okasaki2• 12 years ago

What are you referring to?

leni536• 12 years ago

http://www.hackinglinuxexposed.com/articles/20040705.html

This is why ssh X forwarding disabled by default.

sandGorgon• 12 years ago

Can someone (who is more familiar than me on this topic) comment on whether this is a by-product of Xorg running with root privileges.

The systemd-logind work on Fedora [1] is attempting to run Xorg without root rights (and Wayland/Weston[2] in the future) and I'm wondering if that is a much more effective fix than all this sandboxing ?

[1] https://fedoraproject.org/wiki/Changes/XorgWithoutRootRights

[2] https://plus.google.com/+DavidHerrmann/posts/ggK1tStCvJH

EDIT: longer discussion on Reddit - http://www.reddit.com/r/linux/comments/1viqpt/x_server_runni...

antocv3• 12 years ago

This is not specific to running as root or not, its a problem with X protocol - it doesnt isolate clients.

doctorfoo• 12 years ago

On my last OS reinstall, I tested out Qubes but was put off by the lack of AppVM graphics card support (I do game development) and lack of bluetooth (wireless mouse + headphones) support. I understand these are key security holes and are absent for a reason, but in my view being able to enable these would have been an acceptable compromise between usability and security - the reality is that my personal security situation is not so critical that I am going to go without these modern conveniences, but I would still like to make it as difficult as possible for attackers otherwise.

Surely Qubes even with these security holes would be better than vanilla Linux? (This was roundly shot down as a proposition on the Qubes mailing list)

leoc2• 12 years ago

Will Wayland improve matters significantly?

microcolonel2• 12 years ago

Yes.

ah-• 12 years ago

Yes. See http://mupuf.org/blog/2014/02/19/wayland-compositors-why-and...

leoc2• 12 years ago

Sorry, I missed the earlier comment asking about Wayland.

cmiles74• 12 years ago

Perhaps migrating QubesOS from X to Wayland would provide the groundwork for GPU sharing.

xenophonf2• 12 years ago

Invisible Things Lab published a similar analysis of Windows GUI isolation earlier this year:

http://theinvisiblethings.blogspot.fr/2014/01/shattering-myt...

I find the concept behind Qubes fascinating. I only wish that it was more stable or that it supported native isolation mechanisms like FreeBSD jails.

JupiterMoon• 12 years ago

OK so I get the problem with a program running as a given user being able to grab all of that user's key strokes.

But why try to stop something running as root from grabbing users keystrokes? If someone has root on your box it is pretty much game over for any security anyway. Anything that pretends that it isn't is actively bad since it will give you a false sense of security.

So to mitigate this simply have multiple profiles. One for work, one for banking etc and one with sudo access - and don't su into the sudo access profile just Ctrl-Alt-F1 when needed.

ushi• 12 years ago

Does anybody know, how Wayland [0] handles this? I just found one thread on StackExchange [1].

[0] http://wayland.freedesktop.org/

[1] https://security.stackexchange.com/questions/3589/passive-an...

nemetroid• 12 years ago

This question is asked in the comments of the article as well, and receives an incredibly unprofessional answer:

(commenter) Instructive article. But what about Wayland? Wayland is claimed to replace X soon. Major distros are already working on its integration. Are the authors aware of it or does it have the same design flaws?
(author) @phocean: good question about Wayland, why don't you check for yourself? ;)
(commenter) So I will when I have some free time. But as it is your research topic, I expected you had already done that or even contacted the developers to inform them. As it is still under heavy development, I guess it is a good timing to implement good stuff and for expert like you to advise them.
(author) @phocean: Don't kid me, kid! What I did here was not a "research" (you might want to check some real research we did at ITL on our website). That was just a Saturday morning blog post with an aim to save some lost souls, like yours... And I really don't have time to go and test all the software in the development that is out there. I do have real job, that among other things includes doing real research...

The Linux Security Circus: On GUI isolation

Related Stories