Forgot your password?
typodupeerror
Bug X Graphics Open Source Security Linux

Linux X.org Critical Security Flaw Silently Patched 259

Posted by CmdrTaco
from the pay-no-attention dept.
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.'"
This discussion has been archived. No new comments can be posted.

Linux X.org Critical Security Flaw Silently Patched

Comments Filter:
  • Convenient (Score:5, Funny)

    by rotide (1015173) on Wednesday August 18, 2010 @12:28PM (#33290040)
    So, I'm supposed to click a link to read a PDF about a PDF flaw. You sly boots!
    • Re: (Score:3, Funny)

      by blair1q (305137)

      Just click the popup telling you that your PC is infected. That'll fix it.

  • Blame Xorg (Score:5, Interesting)

    by betterunixthanunix (980855) on Wednesday August 18, 2010 @12:30PM (#33290074)
    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.
  • by master_p (608214) on Wednesday August 18, 2010 @12:32PM (#33290112)

    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?

    • by stagg (1606187) on Wednesday August 18, 2010 @12:34PM (#33290144)
      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.
      • As long as it reaches the security mailing lists, it has all the publicity it needs in terms of reaching "the wrong sort of people". Slashdot isn't exactly a timely or accurate source for whitepapers and public exploits. It would be like a criminal reading the NYT for information about illegal happenings and arrests.
    • by pclminion (145572) on Wednesday August 18, 2010 @12:44PM (#33290314)

      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.

      • Re: (Score:2, Interesting)

        by tuffy (10202)

        I don't think it's all that weird. For example, is a bug that corrupts one's filesystem less critical than a bug that allows unauthorized access? Is a root escalation bug more important than a bug that prevents one's video card from working? They all need to be fixed, but I don't think security implications entitle such bugs to special treatment.

        • by ultranova (717540) on Wednesday August 18, 2010 @01:54PM (#33291240)

          For example, is a bug that corrupts one's filesystem less critical than a bug that allows unauthorized access?

          More importantly, is there a difference? Red Hat 9 had - and perhaps distros still have - this nice system where cron would, once a day, run programs dropped into a directory in /etc with root privileges. Very useful for various packages that required periodical maintenance; but if a filesystem corruption bug would allow one to link an arbitrary file to those directories...

          A bug means that a system behaves in a way it shouldn't. There's always the chance that such unplanned behaviour can be used by an attacker to do nasty things. There is no difference between security critical and other bugs, there's only bugs with known exploits and bugs without. Every bug is a chink in the armor, and every kernel bug should be considered security-critical.

          • Re: (Score:3, Informative)

            by spitzak (4019)

            A filesystem corruption bug that allows one to link an arbitrary file somewhere would allow a much quicker root exploit than relying on cron!

            I think you are thinking about extremely old bugs where cron itself could be convinced to run a program without root privledges as root (or really as the cron job). That is from about 1980 or earlier I think.

          • Re: (Score:3, Informative)

            by VGPowerlord (621254)

            More importantly, is there a difference? Red Hat 9 had - and perhaps distros still have - this nice system where cron would, once a day, run programs dropped into a directory in /etc with root privileges. Very useful for various packages that required periodical maintenance; but if a filesystem corruption bug would allow one to link an arbitrary file to those directories...

            I assume you mean /etc/cron.daily which is still around, along with its hourly, weekly, and monthly counter-parts.

          • by pclminion (145572)
            So, giving system administrators a decent opportunity to triage and sequence their patches and updates in a way that causes less disruption to their users while minimizing actual risk, is something you just don't give a crap about? Is it cold up there on your mountain top?
      • In the end, almost any bug is security related anyway. A denial of service by crashing my system is security related. A denial of service by tying up my ports is security related. Gaining unauthorized access is security related. Gaining more than authorized access is security related. Any bug more serious than a color or a pixel alignment being off in a UI is pretty much security-related, because security means the system is available to authorized, authenticated users and not to anyone else.

  • Is this news? (Score:5, Insightful)

    by mspohr (589790) on Wednesday August 18, 2010 @12:40PM (#33290254)
    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.

    • Re: (Score:3, Insightful)

      by jpapon (1877296)
      Must be a slow day. Conspiracy articles about HAARP causing Moscow to burn, and an article about a security flaw that has been fixed. Fascinating stuff... What's next?
    • by Nerdfest (867930)
      Yes, and quickly in this case too, I think, with a fast fix, and then more solid changes later. You can never really tell whether there was an attack or not. There may have been something targeted at a very specific company, site, or person.
      • Re: (Score:2, Interesting)

        by Anonymous Coward

        Quickly? This flaw has existed for 7 years.

        • It could be there since linux 0.1, so what? all that it matters is that holes are patched when discovered or in the worst case when the first 0days exploits are detected.

          Also thanks to the fact that there probably is no guy in business suit that decides when and if to disclose the vulnerability, I tend to think that this xorg problem was managed well enough.

    • Was there an actual attack? No.

      Woah now junior, you don't know that.

      There have been no reported attacks.

      But now that its out there - it's up to people to update their kernel.

      • by mspohr (589790)
        I think that if there was a reported attack then this would really be NEWS. As it is, this is just a bug fix, not news.
  • can bypass all the Linux fancy security mechanisms, and escalate to root, and compromise the whole system.

    The author who wrote this certainly didn't count SELinux as one of the "fancy" security mechanisms...

    • Actually, he did:

      The attack allows even to escape from the SELinux's "sandbox -X" jail.

      (From the announcement of the attack)

  • Just a few months ago we were blasting Microsoft for taking five weeks to prepare the Ormandy patch. Now we discover that Linux has had a root-privledge exploit for years, was notified, and took two months to fix it, and we get comments like "Must be a slow day." Stay classy (and unbiased), Slashdot.
  • Yes, Linux has security bugs. Yes, Windows has security bugs. Yes Mac has them too.

    As an internet user if I use for daily surfing without all sorts of virus and adware protection how likely am I to get garbage on it that slows it down and fouls my surfing experience? How about the likelihood of getting something truly malicious which makes things stop working altogether or worse yet steals my data? Is there such a thing as virus and adware protection which does not bog the computer down all by itself? B
  • any implementation of an X server has been full of holes and dangers, only an idiot runs X server on a server. Learn the command line, you pussies! Run X server somewhere else!

    • by Blakey Rat (99501)

      only an idiot runs X server on a server.

      Running the server version on a, actual server! IDIOTS!!!

  • by Animats (122034) on Wednesday August 18, 2010 @03:24PM (#33292522) Homepage

    There's still a hole. See Xorg Large Memory Attacks, section 4. [invisiblethingslab.com] Opening a one-page gap in mapped memory at the top of the stack is a workaround, not a fix.

    This looks like bad design. Someone got too cute with the MMU. The basic problem is shared memory between a privileged and a non-privileged program. [wikipedia.org] That just screams "security hole". It was put in to get a performance advantage for graphics-heavy applications on X, probably games. "MIT-SHM" shouldn't be enabled on a production server.

The meta-Turing test counts a thing as intelligent if it seeks to devise and apply Turing tests to objects of its own creation. -- Lew Mammel, Jr.

Working...