X11/X.Org Security In Bad Shape 179
An anonymous reader writes "A presentation at the Chaos Communication Congress explains how X11 Server security with being 'worse than it looks.' The presenter found more than 120 bugs in a few months of security research and is not close to being done in his work. Upstream X.Org developers have begun to call most of his claims valid. The presentation by Ilja van Sprunde is available for streaming."
Is X security really a problem? (Score:4, Interesting)
Aren't we going to replace it with Wayland or something really soon?
XWayland (Score:5, Informative)
Re: (Score:2)
But once enough applications get ported, the more complex and less security-hardened parts of X11 will be paged in only while an X11 application is updating its window.
The flaw in this statement is beyond biblical proportions, and in fact extends into the patently absurd domain of hollywood proportions. It's non-digital counterpart is referenced in #63 of the Evil Overlord List: "Bulk trash will be disposed of in incinerators, not compactors. And they will be kept hot, with none of that nonsense about flames going through accessible tunnels at predictable intervals."
You're suggesting that only having a vulnerability present at certain times mitigates the risk. It does not
Pushing pixmaps around (Score:3)
Re: (Score:2)
This idea of the dumb framebuffer where the application developer has to do a lot of heavy lifting to match the applic
RDP and OnLive (Score:3)
Meanwhile far less powerful hardware is turning up everywhere and is almost always on a network (eg. congested WiFi) that just does not have the bandwidth to take pixmaps put together by more powerful hardware
Then explain how well RDP has worked usably for me even across the Internet to a PC on what the cable company likes to call "slow DSL from the phone company". Is "congested Wi-Fi" worse than DSL's upstream? And explain how OnLive, Twitch, or any other sort of live streaming video works.
RDP uses the Windows display model (Score:2)
RDP's display model is, basically, GDI's; in fact the RDP layer appears to Windows as a display device driver exposing all the usual APIs. Which means that the client can push pixmaps across the link, get a handle to the opaque pixmap object (an HBITMAP in Windows parlance if I remember right), and then issue a draw call that just says "draw this pixmap" (or part of this pixmap).
For a lot of samey-looking GUI applications where elements like button backgrounds and borders are reused, this can add up to a hu
Re: (Score:2)
I can provide benchmarks if you want (Score:4, Insightful)
Worse than X so far in my experience.
My experience differs: RDP tunneled over SSH responds better than X11 over the same tunnel, especially with these newer X11 GUI toolkits that just push lots of pixels to the X server. And no, Windows 8 isn't involved at all; I'm using Remmina on Ubuntu to view Terminal Services on Windows Server 2003.
I really do not think you supplied any more here than "something works so the other thing sux".
If you need, I can perform benchmarks for you of Ubuntu viewing an application on another Ubuntu machine over X11 and Ubuntu viewing the Windows version of the same application over RDP.
Re: (Score:2)
If you need, I can perform benchmarks for you of Ubuntu viewing an application on another Ubuntu machine over X11 and Ubuntu viewing the Windows version of the same application over RDP.
Feel free to do so, but dbIII only cares about outdated applications not using modern toolkits. X has a great advantage over RDP/VNC/etc. when it can do the text rendering server-side. No modern applications use server-side text rendering, of course.
Binary thinking and change for sake of it (Score:2)
Change the "only" to "also" and you've got it. Throwing out what works in my workplace for the sake of fashion would impact on the core business and of course cost me my job.
Such thinking on your part and such personal attacks are of course juvenile, especially since what you are advocating is pre-alpha software with a window manager that cannot even iconify or resize windows yet.
You should be ashamed of yourself
Re: (Score:2)
With respect do it for yourself so that you gain a better understanding of what I'm writing about. While you've been looking into other things I've been looking into
Re: (Score:2)
Same applications or apples to aardvarks?
I was planning on using Firefox for Windows over RDP vs. Firefox for Linux over X11. What problems would you foresee with using this as a test case?
the shape of a box, what's in it and what has changed.
In a lot of cases, the majority of it has changed.
Re: (Score:2)
Understand what I'm writing about yet?
Benchmark results (Score:2)
How did those benchmarks go?
Re: (Score:2)
Meh. Been running RDP over the WAN on everything from congested 128kbit frame links to LAN since 1999. I tried running remote X11 over 10 megabit back in teh day and it sucked.
On area where the free *Nix operating systems really need work is decent remote display server speed, yet somehow, most of the free software people seem to be stuck in 1988 and keep believing fallacies like no RDP having no ability to do rootless remote apps, etc.
Meanwhile, in the real world, RDP works. Far better than remote
Re: (Score:3)
As a matter of interest don't applications just use toolkits like GTK or QT to render an interface? Can't just the toolkits be ported to Wayland with minimal change to the app?
Are we talking about a re-write to make an app Wayland compatible, or a few minor changes and a recompile?
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
the toolkits can implement support for Wayland without changed the major version of the toolkit
This is true provided that a particular major version of a toolkit is still in mainstream support. Consider what happens if, for example, GTK+ 3 gets ported to Wayland but GTK+ 2 does not. In that case, GTK+ 2 applications that aren't ported to GTK+ 3 will need to run in XWayland.
Also the user might run XWayland and then even the old X11-only toolkits will work out of the box.
Previous stories about Wayland have attracted comments to the effect "if most of your apps will be running in XWayland, why even switch to Wayland in the first place?" and I was trying to word my comment to avoid the train of thoug
Re: (Score:2)
Previous stories about Wayland have attracted comments to the effect "if most of your apps will be running in XWayland, why even switch to Wayland in the first place?" and I was trying to word my comment to avoid the train of thought that leads there.
If people don't realise that a sudden system wide change that breaks all applications is bad without an emulation layer for transition I don't think they can meaningfully participate in any conversation about change.
Ask them how they propose the change to IPv6 if they are so clever.
Re: (Score:2)
Re: (Score:3)
Come on now people, let's consider this seriously instead of the silly name calling. Who in Wayland is even thinking about
Re: (Score:2)
Re: (Score:3)
So, thanks to a gratuitous API change, legacy systems without "Wayland" can no longer support newer versions of software.
GUI toolkits will likely continue to support both X11 and Wayland backends, just as many currently support X11, Win32, and Quartz backends.
Re: (Score:2)
First off those kits don't run so well under Quartz or Win32 so well. It is off and on but the support is iffy. I suspect that with X11 the support will be better but the feature set of Wayland fits the mainstream GUIs better. So what I would guess is that the X11 version doesn't get maintained much hence buggy, and is slow.
Re: (Score:2, Interesting)
To my surprise I raise the following question!
The same people who worked on X Org are working on Wayland now!
These people removed a couple of hundret thousands of lines of code from X Org.
They refactored the code.
They cleaned the code.
They think they know what they were doing.
How can we trust them to be sucessful with Wayland ?
Re: (Score:2)
..with a ~50MB overhead..and lack of integration with the rest of the system.
Re: (Score:2)
1) Qt may work well, but KDE does not and razor-qt doesn't even try.
2) Qt works as well on Windows compared to other cross platform kits. It doesn't even support all of Windows though digia is doing a nice job.
Re: (Score:3)
What do you mean "we", kemosabe?
Re: (Score:2)
Even if we do, whan on earth makes you think Wayland is even a bit better?
Re: (Score:2)
Wayland is Linux only, isn't it? What about all those other places that run X.org?
The process (Score:3)
This is a good thing. This is the way it is supposed to work. This is how things get better. A little late, but it good to see this happening.
Re:The process (Score:5, Insightful)
No. I think it's time to throw X out. We'll make a new implementation, complete with everything I use (we'll plan to add stuff you want later), with all new code, because new code never has any security holes!
Re: (Score:2)
To be fair, code rarely contains security holes. It's the instructions you have to worry about.
Re: (Score:2)
... and is always API and binary compatible with all the existing software out there ;-)
Re: (Score:2)
I do not believe that (things are getting better).
I would be really surprised if the real number of holes is going down significantly, the developers are making holes at the same time as these guys are finding them. Perhaps this temporarily gets the hole count down, but after five years the situation will be the same.
The OSS "mind" has been, for 20 years, "a fixed hole is a good thing". Why on earth would it suddenly change to "do not make new holes"?
Obligatory YouTube link (Score:3)
Since media.ccc.de seems down, this video is also on YouTube: https://www.youtube.com/watch?v=n9fANvt0IsM [youtube.com]
Re: (Score:2)
http://berlin.ftp.media.ccc.de/congress/2013/mp4/30c3-5499-en-X_Security_h264-hq.mp4 [media.ccc.de]
When will Wayland contain this essential feature? (Score:4, Funny)
Cue hord of posts demanding that Wayland must die as it can never replicate the mass security violations that X11 contains.
Just look it up people (Score:2)
Wayland is a framebuffer compositor designed to replace a few features in X in a new (and incompatible) way in the interests of speed. It still relies on some stuff made for X, and IMHO that's some of the slowest stuff involved in putting things on the screen (eg. gtk), so it will be a bit of a struggle to get an obvious speed benefit unless improvements are made there as well or it gets it's own toolkit
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
New PSA poster (Score:2)
When you use an Insecure X11 Stack...
You are displaying windows WITH THE NSA!
Yet another reason why they need to whip Wayland into shape.
Re: (Score:2)
Meet the new boss, same as the old boss.
Fucking kill it already (Score:2, Insightful)
X had its day in the sun. I want a responsive and fast GUI with network connectivity being somewhere in 10th place. Make that socket/DRI/whatever they cooked up this year into a module so the rest of us don't suffer.
Re: (Score:2)
if it works, why break or reinvent it?
I've been using X for 25 yrs (or close to it) and it does 99% of what I'd want from a transport/gui/toolkit/windowing system.
vnc works great and its only audio that does not carry over vnc. and I don't care or need that (and there are probably ways around that, too).
we have such fast hardware, I don't get what's wrong with X anymore. even if its 'slow' in code, its not slow in practice!
Re: (Score:3)
Re: (Score:2)
That is a horrible idea.. the last thing we need to do is waste even more performance with useless sandboxing and other jive. There's too much of that going on everywhere else now. Regardless of protocol, having sane toolkits and themes in the first place would go a long way towards making remote desktop quick and responsive even with bad connectivity. This means no stupid pixel shader driven desktops when running in remote mode..
Re: (Score:2)
And the idea is for them to still live on in Wayland.
I still don't see anything in Wayland that things like "evas" can't already give us on X (yes I know that "evas" for Wayland is also in progress).
Re: (Score:2)
Re: (Score:2)
You mean the "rest of us" being that minority that doesn't use and/or doesn't understand X11 network functionality?
Minority? The majority of X11 users will never remote an application.
Re: (Score:2)
Re: (Score:2)
if I count most comments about it, you're out numbered, hence "minority"
When you decided that slashdot was representative of most X11 users, you failed miserably. Almost as hard as X11 fails at security.
Re: (Score:2)
Just once I'd like someone to answer this criticism with something reasonable instead of "No it's Not!!!"
Re: (Score:2)
Rough back-of-envelope counting anyway
You're counting the loud users. Most users of X11 don't even know what an X11 is, or if they've ever heard of X10 that it's not just a crappy home automation standard known for pop-up ads. And that is in fact the way it ought to be. We only know what X11 is because we've had to fight with it to make it do what we want, or because we're working with it directly on some level deeper than the average user.
Re: (Score:2)
Re: (Score:2)
And for every 3 users who do use some kind of remote app and is telling me X11 remote apps is just as good as VNC or RDP, I'd bet there is at least 2 of those 3 that doesn't understand how X11 remote apps works (hasn't used it or doesn't understand the difference) based on what I've heard from people who have tried or who have at least thought about it.
Well, I've used X11, VNC, and RDP, and RDP wins hands down. This is probably because some of the toolkits used with X11 abuse X11, but it does not in fact matter why. The truth is that RDP gives the best results in pretty much every situation in which you're running anything more complex than an xterm. And I do mean xterm, or perhaps color_xterm, but not gnome-terminal or what have you.
Re: (Score:2)
Re: (Score:2)
Ignorance is not a virtue.
Re: (Score:2)
The majority of users never create content either, so should we just get rid of desktops entirely and force developers to use tablets?
Re: (Score:2)
Minority? The majority of X11 users will never remote an application.
Except xeyes
Re: (Score:3)
Re: (Score:2)
Re:Fucking kill it already (Score:4, Informative)
Re: (Score:2)
Examples from your side?
Re: (Score:2)
Re: (Score:2)
It does have a responsive and fast response.. It's the bloated toolkits and useless eyecandy rendering engines sitting under it that are the problem.. Turn off the compositor and it responds just fine, even on ancient late 90s hardware.
Slashdot editing in bad shape (Score:2)
A presentation at the Chaos Communication Congress explains how X11 Server security with being 'worse than it looks.'
Still, at least you didn't just copy and paste, so points for that.
Broken by design (Score:4, Informative)
It is not the way X works is particularly secure to begin with. Once an app has a connection to the X server, it has full control over the world of window, pixmaps and events on the server including of course all other apps.
Not that I have any faith in Wayland or Mir being any better, its developers coming from the X world in the first place, I am sure that they will make their new shiny systems vulnerable in the same ways.
Re:Broken by design (Score:5, Insightful)
Re:Broken by design (Score:5, Insightful)
Doesn't everyone use X over an ssh tunnel anyway? I haven't used a raw X connection in over a decade.....
That doesn't help at all. He's talking about the fact that any X client can obtain information from any other X client on the same server. Tunneling the X clients through ssh doesn't help at all - it just causes the server to make all that information available over ssh.
Granted, the last time I checked linux makes the memory space of every process for any uid available to any other process running under the same uid (unless you're using SELinux). It is just that big unixy trust-everything-local attitude.
Why is this sort of thing bad? Well, now not only can a browser exploit result in a script being able to sniff your keyboard traffic to other tabs in the same browser, it can also sniff your keyboard traffic to every other window on your display, regardless of where those clients are actually running. There are ways to block it, but nobody uses them as they are rather inconvenient (xterm probably still supports it though).
However, until we close the gap of by web browser being able to read my mail directory or modify my .bashrc, I think that X11 vulnerabilities are just the tip of the iceburg.
Re: (Score:2)
Granted, the last time I checked linux makes the memory space of every process for any uid available to any other process running under the same uid (unless you're using SELinux). It is just that big unixy trust-everything-local attitude.
Which mainstream OS does this differently? AFAIK this is the way it works in Windows and OSX aswell, unsure about the BSDs though but I wouldn't be surprised if they also do it like this (it would be a pain to use things like strace or shared memory otherwise and the MMU tables would be quite big)
Re: (Score:2)
Granted, the last time I checked linux makes the memory space of every process for any uid available to any other process running under the same uid (unless you're using SELinux). It is just that big unixy trust-everything-local attitude.
Which mainstream OS does this differently?
Linux under SELinux potentially does this different. I guess you could also count Android - as it gives each application a separate uid, though access to the sdcard is all-or-nothing.
However, yes, this is a common vulnerability, and just another reason why the world is crawling with worms.
Re: (Score:2)
Which mainstream OS does this differently?
When I was reading up about this a few months ago, it was noted that Windows Vista fixed this on the Windows line. So, yeah, even Windows 8 does something better than a GNU/Linux desktop.
The SELinux fix has been roughed out, but it's not very usable and certainly not mainstream.
I was really disappointed to read that Wayland would possibly bolt this on later, but had nothing baked into the core protocol.
Re: (Score:2)
Actually, Android comes to mind. Each application is locked in its own little world (except apps from the same developer) and can only talk to other apps via API calls they've previously agreed on or published.
Its actually quite a nice model.
Re: (Score:3)
Re: (Score:2)
Granted, the last time I checked linux makes the memory space of every process for any uid available to any other process running under the same uid (unless you're using SELinux). It is just that big unixy trust-everything-local attitude.
I am a bit of bearded unix burnout but... For goodness sakes. It has nothing to do with "unixy trust-everything-local attitude". It has everything to do with _the uid security model_. The security model is not "trust everything local", it is "each user(by id) can run a bunch of programs, and those programs are all _by design_ able to communicate (or interfere) with any other program run by the same user". Yes, in practice, we find many unix systems where there is effectively only a single user, and the
Re: (Score:2)
Yes, in practice, we find many unix systems where there is effectively only a single user, and the biggest security threat vector against that user is *not other users on the system* but *programs the user decided to run that were not sufficiently vetted to be free of (remotely) explotable bugs and backdoors*
So, I agree with everything you said, but if I only ran software sufficiently vetted to be free of exploitable bugs and backdoors I wouldn't be running just about anything. Certainly I wouldn't be running the Linux kernel, or any web browser. I'm sure there are a few small programs that are sufficiently small that you could completely characterize their behavior if you limited it to a very particular intended use.
Half the stuff on the NSA Christmas list of exploits probably involves zero-days for mainstre
Re: (Score:3)
the X server itself is root which makes the X server a big target
Good point. With KMS I'm not quite sure why it still is root, but sure enough mine is...
Strictly speaking, we already have that capability in SELinux or in AppArmor. The reason it's not really heavily implemented is because you might want your web browser to be able to save a file in your mail directory or overwrite your local .bashrc from a server stored copy somewhere. Meanwhile, sticking all the UI stuff to allow/disallow isn't some magic bullet...
Oh, I agree. The problem is that nobody has figured out a good model for app-level security that isn't extremely inconvenient.
However, I still think the status quo is really insecure. The fact that nobody has come up with something that works better doesn't change that. Sure, if your browser doesn't contain an exploit then you don't need the extra security, but if you want security then you really need defense in dep
Re: (Score:2)
X clients tunnelled over X are untrusted X clients and do not have access to everything by default. See X security extension and the -Y option of ssh.
True, but that would apply only to the clients going through the tunnel. Well, assuming it works (on my distro ssh X11 forwarding without -Y doesn't work at all).
Re: (Score:2)
What do you mean that X forwarding is not working? It is usually deactivated by default and you have to turn it on with -X or in a config file. If you use '-Y' you turn off security. You have no reason to complain, if you turned security off yourself.
Looked it up. Openssh secure forwarding only works if the X server is compiled with XC-SECURITY enabled, which is disabled by default. Some distros consider it insecure, as does upstream. So, on distros that do not override this and enable XC-SECURITY secure Openssh forwarding is disabled. If you use openssh -X to connect you get the error "Warning: untrusted X11 forwarding setup failed: xauth key data not generated." X11 forwarding does not work in this case. Using -Y works fine.
There is some relevan
Re: (Score:2)
Yeah, was a bit frustrating when I finally figured out why it was broken, especially since the error message isn't exactly helpful.
Re: (Score:2)
That actually makes the problem worse. Once you have forwarded your X connection with ssh -Y, everyone who can get the security token on the machine you ssh into (e.g. at least root) can sniff your keystrokes. If you do ssh -X instead, the damage they can do is limited (well except for X bugs), but few things actually work so -X is rarely used.
X is pretty unique in that respect, other remote desktop protocols generally do not have local keyboard sniffing built in as a feature (although I think some of them
Re: (Score:2)
What claims?
Not just X.org (Score:3)
Re: (Score:3)
The Qt part left a bit of a bad taste in my mouth, so I did some research of my own.
The first thing to notice is that a normal Qt application has no attack surface, there is no need for any part of the application to use elevated privileges. So what was his point? The presenter went with the assumption that some applications can be started as a normal user but get root rights by being installed as suid-root.
I don't understand why he would attack that idea. Having a GUI app started by any user run as roo
Re: (Score:2)
Re: (Score:2)
Qt has hundreds of committers from dozens of companies, if he can' t get his patches accepted, did you consider they were of low quality or in violation of the guidelines?
Re: (Score:3)
Since moving to Open Governance, we're very open to external input: we're just very demanding, that's all. You can't expect us to just blindly accept any drive-by patch submission, or any security report from a self-proclaimed security expert. There's a process to follow, standards to reach, and it takes time to convince Qt maintainers that your patch or security concern is correct, let alone meets the quality standard required. If you're not prepared to stick around and defend your patch/security issue/
Re: (Score:2)
Ah, if that wasn't so funny, I wouldn't bother replying :-) Corporate? Neither I nor the security guy who discussed this are employed to work on Qt, we're from KDE and this is all in our own time. Boilerplate? Nope, in true Slashdot tradition it's just off the top of my head :-) Tons of alternatives? Name one. Even Linus has moved to Qt for its cross-platform abilities, no other toolkit comes close, and its our demanding standards that keeps people using Qt. We'll be around long after AC's like you
Re: (Score:2)
Hey Wonko,
this is totally unrelated to this post of yours. In the C+= discussion thread, you post about a tweet on twitter calling for job terminations or similar, the link is broken now, do you have a backup somewhere?
Cheers & thanks!
Re: (Score:2)
well of course... (Score:2)
Re: (Score:3)
Given that X is nearly 30 years old... it sounds more like a number of issues were not considered way back when (trust boundaries for one), and that those same mistakes/assumptions have been carried forward for much of this time.
Re:Hotel 1 Bravo (Score:5, Insightful)
Some were certainly considered but prohibited by law. Due to crypto export restrictions, it wasn't until the limits on Open Source were loosened that X was legally permitted to have any kind of meaningful security. The non-export version still had to talk to the exportable edition, after all.
Yes, X was (and is) incredibly sloppy by today's standards and yes a lot of that was due to poor decisions in the days of X10. (Yes, boundaries are a decision. MIT could have chosen any sort of access control list system they wanted, with yet another library handling it. You could have then substituted whatever you wanted, so long as the API remained the same. Pretty much futureproof, no significant extra coding, easier to maintain than what they actually did.)
The coding flaws - of which there were many - were often detectable by tools as ancient as lint.
But you must also remember, X10 and X11 were never intended as products. They were reference implementations of a protocol, not finished products intended for actual use. The different vendors were always "supposed" to provide their own.
Re: (Score:2)
Given that X is nearly 30 years old... it sounds more like a number of issues were not considered way back when (trust boundaries for one), and that those same mistakes/assumptions have been carried forward for much of this time.
God I hate that word. If there is one word that I wish I could beat out of every developer, it's "assumption". I know they are necessary to an extent, but man do they come back to bite you in the ass every time...
Re:ANOTHER Phoronix post? (Score:5, Insightful)
I'm sorry. You were complaining about a news (Yes, news) story about a talk from CCC (Which is highly popular with, and immensely relevant for, nerds), posted on Phoronix (A website that devotes itself almost entirely to information, news and reviews on hardware and software from a Linux-based perspective), about a lot (120+) of security holes (Things that matter) in the X11/X.org servers (Which are the basis for (almost) all GUI-driven applications in Linux, *BSD and some of OSX).
By my count, that makes this story "News", "For Nerds", and "Stuff that matters". Oh, and the irony in posting that Phoronix is a "Link Farm" on /. is almost entirely palpable.
Re: (Score:2)