Slashdot Mirror


Linux X.org Critical Security Flaw Silently Patched

eldavojohn writes "On June 17th, the X.org team was notified by Invisible Things Lab of a critical security flaw (PDF) that affected both x86_32 and x86_64 platforms. The flaw deals with escalated privileges of a user process that has access to the X server. The founder of ITL said of the flaw, 'The attack allows a (unpriviliged) user process that has access to the X server (so, any GUI application) to unconditionally escalate to root (but again, it doesn't take advantage of any bug in the X server!). In other words: any GUI application (think e.g. sandboxed PDF viewer), if compromised (e.g. via malicious PDF document) can bypass all the Linux fancy security mechanisms, and escalate to root, and compromise the whole system.' This has apparently been a security flaw since kernel 2.6 was released. From the article, 'On 13 August, Linus Torvalds committed an initial fix, but several patches were added afterward for various reasons. The problem has been addressed in versions 2.6.27.52, 2.6.32.19, 2.6.34.4 and 2.6.35.2 of the kernel.'"

15 of 259 comments (clear)

  1. Convenient by rotide · · Score: 5, Funny

    So, I'm supposed to click a link to read a PDF about a PDF flaw. You sly boots!

    1. Re:Convenient by NNKK · · Score: 4, Insightful

      Do you honestly think that Microsoft would do nothing if there was a non-patched privilege escalation exploit in Windows?

      What rock have you been living under?

    2. Re:Convenient by Anonymous Coward · · Score: 5, Informative

      What are you on about? There a full changelog for the patched code. Do you have any idea how much changes in the linux tree each week? One bugfix is not going to make news other than from a pro-Windows news outlet attempting to make it appear there's a cover up. Try reading LKML if you're stupid enough to think there's a conspiracy going on.

    3. Re:Convenient by Score+Whore · · Score: 5, Informative

      Contrary to the headline written by an idiot, this isn't an Xorg bug. It's a kernel bug that can be exploited through Xorg.

  2. Blame Xorg by betterunixthanunix · · Score: 5, Interesting

    Xorg is a mess. Fedora had to craft a special SELinux policy, which exempted Xorg from a number of restrictions that apply to other applications (for example, the ability to unset the NX bit on a region of memory), because not only does Xorg do so many questionable things, but there is no good way to fix it. That, and the fact that Xorg runs as root, make it a particularly weak link in the chain.

    --
    Palm trees and 8
    1. Re:Blame Xorg by vadim_t · · Score: 4, Interesting

      That should be fixed eventually. With the switch to kernel modesetting (already happening) there shouldn't be any need for X to mess directly with hardware anymore, and without that it should run just fine without root privileges.

    2. Re:Blame Xorg by Cyberax · · Score: 4, Informative

      Yep.

      On Linux input devices are now moved into the kernel. The only complex thing remaining is modesetting and hardware acceleration. But they are being fixed as well.

      In fact, you can run 'rootless X' on Fedora ( http://lwn.net/Articles/341033/ ) and soon on Ubuntu ( https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-maverick-rootless-x ). Here 'rootless' means that the server doesn't require root privileges to work.

  3. How much more 'silent' was than other bugs? by master_p · · Score: 4, Insightful

    Do the Linux developers put a news announcement out every time there is a bug and they forgot about it this time?

    Isn't it a little sensational to imply that Linus and the other people didn't want this bug to be known because they fear Linux will be characterized as buggy?

    1. Re:How much more 'silent' was than other bugs? by stagg · · Score: 4, Insightful

      I'd rather hear about a flaw like this after the fact frankly. I don't think an unpatched exploit needs the kind of publicity that /. would get it.

    2. Re:How much more 'silent' was than other bugs? by pclminion · · Score: 4, Informative

      Do the Linux developers put a news announcement out every time there is a bug

      No, but all changes to the kernel are documented in the changelog. And security-related bugs are treated the same as any other bugs. They are not explicitly called out as being security related. Linus has been pretty clear on this in the past. A bug is a bug, period. The fact that it's security related is uninteresting (to him, at least).

      I think that's a weird attitude but that's what we've got.

  4. Re:What I suggest to people by stagg · · Score: 5, Funny

    You do realize that Mac is built on a FreeBSD kernel?

    Macs can't be exploited. That's why people paid to get into the walled garden, it's safe in there. LA LA LA LA LA LA I CAN'T HEAR YOU.

  5. Is this news? by mspohr · · Score: 4, Insightful
    Isn't this the way it's supposed to work?

    1. Bug found, responsible parties notified

    2. Bug fixed and software updated

    3. We are protected from potential future attacks. (Profit!)

    Was there an actual attack? No.

    --
    I don't read your sig. Why are you reading mine?
  6. Re:What I suggest to people by l2718 · · Score: 4, Informative

    You do realize that Mac is built on a FreeBSD kernel?

    Actually, MacOS uses the Mach microkernel in a BSD system; some code was taken from FreeBSD -- but not the kernel.

  7. Re:What I suggest to people by bsDaemon · · Score: 4, Informative

    Darwin is their codename for what is the open source bits of MacOS X. The kernel is largely based on Mach. Since its a Microkernel, it can have "servers" for different subsystems, including BSD, which aren't really "kernel modules" in the Linux or BSD sense. A lot of the userland and C libraries are derived from FreeBSD, with some GNU stuff, and custom changes to both. They did hire a bunch of big-name FreeBSD people though, like Jordan Hubbard, which just contributes extra confusion to a confusing situation.

  8. Ad hominem by benjymouse · · Score: 4, Interesting

    Here is a novel idea: Stop misrepresenting what actually happened and stop ad hominem attacks questioning posters' motives .

    Microsoft took five weeks to prepare the Ormandy patch. During that time, they made no comment - there was no transparency into whether or not it would be fixed.

    They made no comments? Did you actually look or did you just assume?

    • Tavis Ormandy reported the issue June 5th (a Saturday). He wanted MS to commit to a 60-days timeline.
    • Tuesday (a busy patch Tuesday, no less) MSRT get back to him and say they can present a schedule the upcoming Friday, June 11th (which is less than 5 workdays after the bug report).
    • Not good enough for Ormandy he goes public immediately, Wednesday June 9th on the 3rd workday after reporting the bug

    Now to your claim that they "made no comments":

    Hardly a "no comments" approach. If you click through those posts I think you'll find them smack full of info. And I've even excluded their communication on the preliminary "fix it" tools.

    Admit it. You are biased, but not classy.

    Like your misrepresentation and ad hominem demonstrate more class?

    It seems to me that it is indeed interesting that this fix was 2 months in the making (responsibly disclosed). And that is only measuring the time until the kernel had been fixed. Now the distros would have to pick up on it and perform their own regression testing, prepare packages/updates etc.

    GP did raise some really interesting questions. For some reason you chose to disregard them right away and go straight for the mans posting history.

    Will you be publishing stats on my posting history as well. Am I a shill, too?

    --
    Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*