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

3 of 259 comments (clear)

  1. 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. 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*