Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Security

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."
This discussion has been archived. No new comments can be posted.

X11/X.Org Security In Bad Shape

Comments Filter:
  • by Anonymous Coward on Tuesday December 31, 2013 @06:08PM (#45833311)

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

    • XWayland (Score:5, Informative)

      by tepples ( 727027 ) <tepples.gmail@com> on Tuesday December 31, 2013 @06:24PM (#45833391) Homepage Journal
      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 [freedesktop.org]. 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.
      • 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

        • 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?
          • by dbIII ( 701233 )
            Yes the brute force approach of pushing pixmaps around which only does it well because ridiculously powerful graphics hardware makes it possible. 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 (and certainly can't do much itself).
            This idea of the dumb framebuffer where the application developer has to do a lot of heavy lifting to match the applic
            • 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'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

      • 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?

        • by tepples ( 727027 )
          We're talking about 1. porting the toolkits and 2. porting the applications to the latest versions of the toolkits. Step 2 can be a few minor changes, recompile, and run through the project's acceptance testing procedure. Or it can be far more involved if any of the following are true:
          • The application currently uses a toolkit that won't be ported to Wayland. Among X11 toolkits [wikipedia.org], Qt and GTK+ will be ported, but many others won't.
          • The application currently uses an old major version of a toolkit. Applications t
          • Step 2 can also be "do nothing" since the toolkits can implement support for Wayland without changed the major version of the toolkit so the application can link to the very same .so as it did before. Also the user might run XWayland and then even the old X11-only toolkits will work out of the box.
            • by tepples ( 727027 )

              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

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

              • Yes that is true but there is also great motivation from the Wayland and MIR developers to implement support in the current toolkits so even if support won't happen in the stable version from upstream it's quite likely that we will get it anyways. For example Canonical have implemented MIR support in both SDL1.2 and SDL2.x. I assume here that they are also working on GTK2 and Qt, and something tells me that Red Hat will do the same for Wayland.
      • by dbIII ( 701233 )
        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
        • by smash ( 1351 )
          It's about making the simple dumb framebuffer do simple dumb framebuffer stuff and moving the other complexity out of the simple dumb framebuffer to better seperate security, etc. You don't have a single do everything command line tool, you have multiple small tools you can link together with pipes. This is no different.
    • by fnj ( 64210 )

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

      What do you mean "we", kemosabe?

    • by jhol13 ( 1087781 )

      Even if we do, whan on earth makes you think Wayland is even a bit better?

    • by npcole ( 251514 )

      Wayland is Linux only, isn't it? What about all those other places that run X.org?

  • by ebonum ( 830686 ) on Tuesday December 31, 2013 @06:17PM (#45833363)

    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)

      by dasunt ( 249686 ) on Tuesday December 31, 2013 @09:35PM (#45834435)

      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!

    • by jhol13 ( 1087781 )

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

  • by DaHat ( 247651 ) on Tuesday December 31, 2013 @06:38PM (#45833475)

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

  • by blackpaw ( 240313 ) on Tuesday December 31, 2013 @06:43PM (#45833507)

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

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

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

    • 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!

      • by smash ( 1351 )
        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.
    • by fikx ( 704101 )
      You mean the "rest of us" being that minority that doesn't use and/or doesn't understand X11 network functionality?
      • 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.

        • by fikx ( 704101 )
          if I count most comments about it, you're out numbered, hence "minority"
          • 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.

            • by fikx ( 704101 )
              Slashdot's not the only place I count. Other web sites and forums seem to be the same. Rough back-of-envelope counting anyway...no need to do more than that considering the counter replies don't even do that.
              Just once I'd like someone to answer this criticism with something reasonable instead of "No it's Not!!!"
              • 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.

                • by fikx ( 704101 )
                  To be optimistic for Linux adoption, I'd estimate that for every person who does nothing in terms of remote apps or desktops there are 2 users who do (have to count business, campus, etc. users who are on a large network where such things are every day events). Linux still has a lot of it's users in technical areas or who are technical even at home (home network, etc.) as opposed to just home users. So I's say we've got 2/3 of the Linux users doing remote work of some kind. And for every 3 users who do use
                  • 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.

                    • by fikx ( 704101 )
                      My experiece is opposite: used vnc, rdp, citrix, X11, etc. etc. And X11 is always better. In fact use rdp and pcoip daily and don't enjoy it compared to X11.
        • by dbIII ( 701233 )
          Since that minority is huge and includes just about every linux desktop used for work purposes and a pile of MS Windows machines with X to run remote stuff as well I consider it a minority worth listening to.
          Ignorance is not a virtue.
        • by epyT-R ( 613989 )

          The majority of users never create content either, so should we just get rid of desktops entirely and force developers to use tablets?

        • Minority? The majority of X11 users will never remote an application.

          Except xeyes

        • by smash ( 1351 )
          ... 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.
    • by epyT-R ( 613989 )

      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.

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

    by Misagon ( 1135 ) on Tuesday December 31, 2013 @07:04PM (#45833635)

    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.

    • by phantomfive ( 622387 ) on Tuesday December 31, 2013 @08:08PM (#45833987) Journal
      Doesn't everyone use X over an ssh tunnel anyway? I haven't used a raw X connection in over a decade.....
      • by Rich0 ( 548339 ) on Tuesday December 31, 2013 @08:48PM (#45834225) Homepage

        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.

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

          • by Rich0 ( 548339 )

            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.

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

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

        • 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

          • by Rich0 ( 548339 )

            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

      • by amorsen ( 7485 )

        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

  • by Wonko the Sane ( 25252 ) * on Tuesday December 31, 2013 @07:43PM (#45833867) Journal
    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.
    • by zander ( 2684 )

      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

      • This is not the account I've heard about the Qt team being hostile to external input. I know someone working on a Qt application who frequently has to work around c++11 and javascript bugs, and is unable to get any of his patches accepted upstream.
        • by zander ( 2684 )

          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?

        • by Danious ( 202113 )

          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/

        • by sploxx ( 622853 )

          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!

  • ... running a massive service such as that with elevated privileges...

Don't tell me how hard you work. Tell me how much you get done. -- James J. Ling

Working...