Slashdot Mirror

← Back to Stories (view on slashdot.org)

X11/X.Org Security In Bad Shape

Posted by Soulskill on from the i-blame-the-schools dept.

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

29 of 179 comments (clear)

  1. Is X security really a problem? by Anonymous Coward · · Score: 4, Interesting

    Aren't we going to replace it with Wayland or something really soon?

    1. Re:Is X security really a problem? by fnj · · Score: 2

      Aren't we going to replace it with Wayland or something really soon?

      What do you mean "we", kemosabe?

  2. The process by ebonum · · Score: 2

    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.

    1. Re:The process by dasunt · · Score: 4, Insightful

      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.

      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!

  3. XWayland by tepples · · Score: 4, Informative

    Every X11 server needs a rendering target. For some X11 servers, this is a video card. For others, it is a virtual frame buffer that gets served through X11VNC or XRDP. And on machines running Wayland, the X11 server will render to the Wayland compositor. Porting an application's GUI toolkit allows the application to bypass XWayland, but not all applications will be ported to Wayland immediately, especially proprietary software no longer under mainstream support and free software without a large enough user base. 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.

    1. Re:XWayland by tepples · · Score: 2

      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.

    2. Re:XWayland by thegarbz · · Score: 2

      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?

    3. Re: XWayland by Anonymous Coward · · 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 ?

    4. Re:XWayland by dbIII · · Score: 2

      That's right. An upgrade from a complex network aware system with lots of places for bugs to hide to a simple dumb framebuffer where there are less places for bugs to hide. That's fine so long as a simple dumb frame is all you need and so long as it doesn't have lots of places to hide in bits designed to do shiny 3D things thrown together quickly without considering security at all.

      Come on now people, let's consider this seriously instead of the silly name calling. Who in Wayland is even thinking about doing it as a secure system yet? I hope that's the way it goes but it's not happening this early in the project What is it with all these "X sux for a problem that Wayland hasn't even considered yet but will sort out someday" posts?

  4. Obligatory YouTube link by DaHat · · Score: 2

    Since media.ccc.de seems down, this video is also on YouTube: https://www.youtube.com/watch?v=n9fANvt0IsM

    --
    Help Brendan pay off his student loans
    1. Re:Obligatory YouTube link by GioMac · · Score: 2

      http://berlin.ftp.media.ccc.de/congress/2013/mp4/30c3-5499-en-X_Security_h264-hq.mp4

      --
      "It feels like I'm at the Zoo when reading this thread - I'm frightened, but it's interesting" (c)
  5. Re:Hotel 1 Bravo by DaHat · · 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.

    --
    Help Brendan pay off his student loans
  6. When will Wayland contain this essential feature? by blackpaw · · Score: 3, Funny

    Cue hord of posts demanding that Wayland must die as it can never replicate the mass security violations that X11 contains.

  7. Re:ANOTHER Phoronix post? by Anaerin · · 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.

  8. Broken by design by Misagon · · Score: 3, 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.

    --
    "We mustn't be caught by surprise by our own advancing technology" -- Aldous Huxley
    1. Re:Broken by design by phantomfive · · Score: 4, Insightful

      Doesn't everyone use X over an ssh tunnel anyway? I haven't used a raw X connection in over a decade.....

      --
      "First they came for the slanderers and i said nothing."
    2. Re:Broken by design by Rich0 · · Score: 4, 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.

    3. Re:Broken by design by Rich0 · · Score: 2

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

      I think something that the NSA has recently demonstrated is that a lot of software contains zero-days known to very few. The more defense in depth you have, the harder it is to exploit your systems. If you're relying only on perimeter security then you're up the creek when somebody breaches it. Of course, the fact that they're sticking rootkits in the firmware also points to the fact that you need to control the bootstrap from a known-good state. What we really need is secure boot that starts from a trustworthy FOSS loader implemented in ROM that verifies and proceeds into flash for UEFI, and then verifies/loads the OS. Maybe store the ROM's verification certificate in flash which is protected against writing by a hardware switch (that way you can install your own UEFI and configure its trust settings). Of course, all of this only works if you trust your hardware vendor.

      However, this might be a bit of a pipe dream. Linux has had Trusted Grub for eons and who uses that?

    4. Re:Broken by design by fisted · · Score: 2

      Especially the user.

      --
      CLI paste? paste.pr0.tips!
  9. Pushing pixmaps around by tepples · · Score: 2

    I intended to emphasize "more complex" rather than "less security-hardened". There's plenty of "more complex" legacy stuff in X11 that almost no modern application uses; most GUi toolkits nowadays just push pixmaps around. The featured article describes the effort to fix the "less security-hardened" part, but the only way to break with "more complex" is to ditch X11 in favor of something that does one thing (push pixmaps around) and does it well. Isn't that what the UNIX philosophy is supposed to be anyway?

  10. Re:Hotel 1 Bravo by jd · · 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.

    --
    It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
  11. Not just X.org by Wonko+the+Sane · · Score: 2

    Based on the Qt team's complete lack of willingness to fix security bugs apparently when you render with Qt, you're rendering with the NSA.

    1. Re:Not just X.org by zander · · Score: 2

      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 root is not good security policy. Having your app run as root and linking it to multi-megabytes of library that is not hardened for such a case is just plain silly.

      The answer of the Qt guys makes a lot of sense, the library is not meant to be run with different privileges as the user that started it. He should have gotten the point when the Qt security experts made the point clear with the plugins. If I can start an app as root from my normal user, and I can specify which styling-plugin to run, I essentially can tell it to run my code. As root.

      So, I'm fully satisfied with the answer that Qt is not wrong, it doesn't have an attack surface unless the app using it is doing something stupid.

      His security report is akin to blaming the vim authors that it is a security concern if you install it as suid-root. Its blaming the wrong person for introducing the attack surface.

      ps. his quoted Qt code never occurs in any of the Qt5 codebase as far as I can find.

    2. Re:Not just X.org by Danious · · Score: 2

      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/bug report from robust questioning then why should we trust you? I'm a Qt maintainer, one of the first to be appointed under Open Governance from outside Nokia/Digia, and it still takes me several revisions before my patches get approved! It's hard work, simply because quality matters in a toolkit like Qt, especially with security issues.

      As for the original article, well the issues were discussed with Qt in March last year, and our security expert at the time said we don't support running a Qt binary as setuid, nor does any gui toolkit, so the issue is not really our problem, the problem is with the fool who runs with setuid. However, in response to the publicity, he has now posted a patch to make this very explicit https://codereview.qt-project.org/#change,74531

  12. Re:Fucking kill it already by fikx · · Score: 3, Informative

    All X11 apps "support" it...that's the beauty of X11 network functionality: apps don't HAVE to support it, it comes free.

    --
    AB HOC POSSUM VIDERE DOMUM TUUM
  13. RDP and OnLive by tepples · · Score: 2

    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.

  14. Re:Fucking kill it already by smash · · Score: 2

    Because it only works for very generous definitions of "works". If you've never used anything else maybe remote X seems like it rocks, but vs. ICA or RDP (even the versions from 1999) its performance is abysmal.

    --
    I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
  15. Re:Fucking kill it already by smash · · Score: 2

    ... and remote X sucks balls really bad anyway. It's passable on gigabit ethernet, anything slower than that and it is pretty horrible. Meanwhile, even RDP is usable over 64 kilobit.

    --
    I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
  16. I can provide benchmarks if you want by tepples · · Score: 3, 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.