Forgot your password?
typodupeerror
Bug Security SuSE Linux IT

Root Privileges Through Linux Kernel Bug 131

Posted by timothy
from the who-needs-windows? dept.
Lars T. writes "The H has a story about a Linux kernel bug that allows root level access. 'According to a report written by Rafal Wojtczuk (PDF), a conceptual problem in the memory management area of Linux allows local attackers to execute code at root level. The Linux issue is caused by potential overlaps between the memory areas of the stack and shared memory segments.' SUSE maintainer Andrea Arcangeli provided a fix for the problem in September 2004, but for unknown reasons this fix was not included in the Linux kernel. The bug is not related to the X Server bug found by Brad Spengler." As the linked article notes: "SUSE itself has the fix and SUSE Linux Enterprise 9, 10 and 11 as well as openSUSE 11.1 through 11.3 do not exhibit this vulnerability."
This discussion has been archived. No new comments can be posted.

Root Privileges Through Linux Kernel Bug

Comments Filter:
  • by Anonymous Coward on Thursday August 19, 2010 @05:41PM (#33307782)

    How can the two bugs be unrelated? both articles have the exact same link to the exact same PDF! (Hint: the pdf's filename is xorg-large-memory-attacks.pdf on both).

    • by NeverVotedBush (1041088) on Thursday August 19, 2010 @06:02PM (#33308006)
      I think what it is is that the Xorg server is an easy attack vector for the Linux kernel memory management issue.

      The memory management issue is the thing that enables using a flaw in the X server to escalate privilege. If you fix the X server to not allow that kind of manipulation, you still have the kernel memory management issue that could be used by some other application to escalate privilege.

      I think that fixing the X server - one mitigation is to disable the MIT-SHM extension as discussed in the pdf - really reduces the exposure but since the real problem is in the kernel, it doesn't completely remove the threat.

      At least that is how I understand it...
      • Re: (Score:3, Informative)

        by bjourne (1034822)

        I think that fixing the X server - one mitigation is to disable the MIT-SHM extension as discussed in the pdf - really reduces the exposure but since the real problem is in the kernel, it doesn't completely remove the threat.

        The shm extension is integral to all modern xorg servers. You *may* be able to run xorg without shm, but many programs will refuse to work and performance will drop to a few percent of what it is with shm enabled. It's the transport the X server uses for communication with its client. With shm (shared memory) disabled, it has to serialize all objects and send them over a socket which of course is dog slow.

        • by mzs (595629)

          Hmm... It's really the pixmaps that are way faster over MIT-SHM. If you are local than the unix domain socket is not all that much slower, there is an extra copy involved. With the pixmap you can just modify the image directly. Though there was a long time where this was not universal, and when you expected it to work sometimes it did not since the 2D acceleration in the driver broke it since the pixmap was really in framebuffer memory.

          But for a long time people have been doing XShmQueryVersion() and only u

    • Re: (Score:3, Funny)

      by Tumbleweed (3706) *

      How can the two bugs be unrelated? both articles have the exact same link to the exact same PDF! (Hint: the pdf's filename is xorg-large-memory-attacks.pdf on both).

      The identical links are caused by another bug called PEBKAC.

    • by lortho (700090) on Thursday August 19, 2010 @06:13PM (#33308116)
      It's because both articles are actually about the Wojtczuk report, and they both mis-quote Joanna Rutkowska as stating the bug is related to Spengler's X-Server flaw. She clarifies in an update to H-Online's version of the article that she was misunderstood and that they are actually unrelated.
  • by interfecio (1023595) on Thursday August 19, 2010 @05:51PM (#33307898)
    From the RedHat bug report: Eugene Teo (Security Response) 2010-08-12 21:44:06 EDT Linus has committed a fix for this issue: http://git.kernel.org/linus/320b2b8de12698082609ebbc1a17165727f4c893 [kernel.org]
    • by JohnFluxx (413620) on Thursday August 19, 2010 @06:07PM (#33308058)

      I don't agree that it's "nothing to see here" - something has gone wrong if it took 6 years for this to happen.

      • Re: (Score:2, Funny)

        by Anonymous Coward

        Here at Linux Vintners, we will commit no bug fix before its time.

        This properly aged bug fix boasts an intense, highly indented C syntax and fragrant blackberry, vanilla, and dark chocolate comment style with just a hint of peppercorns. Richly textured and firmly structured, its lavish blackberry, ripe black plum, dark cherry and spice flavors are enlivened by crisp lint-warning-free compilations. Given its superb balance of fruit, oak, acid and tannin, this sumptuous contextual patch aged beautifully for 6

      • by petermgreen (876956) <plugwash@p10link ... inus threevowels> on Thursday August 19, 2010 @06:47PM (#33308446) Homepage

        Agreed it would be good to know where the breakdown in communication happened. Did it get ignored because the submitter didn't realise it was a security issue and report it as such? Did someone just miss an email somewhere? (and if so why wasn't there a system in place to keep track of current security bugs and make it bloody obvious which ones still needed fixing along with someone responsible for looking at that list and fixing them). Was the breakdown on the SUSE side or the upstream side?

        • by jittles (1613415) on Thursday August 19, 2010 @08:24PM (#33309204)
          My guess would be an oversight at kernel.org. I submitted a kernel patch to the USB HID driver back in the days of 2.6.10 and 2.6.13. The driver was incorrectly suspending its state (I can't remember what it was doing off the top of my head) while it held onto a spinlock. The result was 100% CPU utilization when you called certain ioctls made available by the driver. The patch didn't make it in until 2.6.17 if I recall correctly, and not until someone with a name submitted a patch for it.
          • by Chirs (87576) on Friday August 20, 2010 @02:10AM (#33310930)

            If you really want to get a fix in, the correct procedure is to keep pestering the maintainer for that area until they accept your patch. If you can't get them to accept it, you go up the chain.

            Yes, in an ideal world all maintainers would be perfectly organized. In the real world things get lost, they get distracted, other issues pop up, and the patch doesn' t make it in.

            If you care about it...make some noise.

            • Re: (Score:3, Insightful)

              by Kjella (173770)

              But the problem is that often if you know about it, it's not really a big issue to you. If I know about an ugly pothole in the road, I can with little effort drive past it. So why then should I spend my valuable time pestering the road maintainers about it? Granted, maybe not in this specific case as you can't avoid the security hole but bugs in general you can often avoid the condition triggering the bug.

              The first time you tell them, then maybe the only reason it's not fixed is because nobody told them abo

            • Re: (Score:1, Interesting)

              by Anonymous Coward

              "...the correct procedure is to keep pestering the maintainer..." wow, THAT's a screwed up procedure. If I go through the effort of identifying a flaw and submitting a patch and the maintainer doesn't acknowledge my existence, the hell I'm going to keep pestering him...

              I mean THAT's the reality of it, it isn't that the maintainer just misplaced the e-mail. E-mails from Linus don't get accidentally misplaced. So why should e-mails reporting and fixing vulns get misplaced? It's BS and it's a little elitist cl

    • by _Sprocket_ (42527)

      Isn't it something to see / know about until one gets that fix out to the kernel on our live system(s)? We expect a speedy fix. Now begins the race to get the fix live.

      • And I raise a mug of coffee to all my fellow sysadmins this evening. There goes my damned server uptime, and here comes my damned conscious uptime.

        Sleep... she is for the weak!

      • Re: (Score:3, Informative)

        by LingNoi (1066278)

        Race?

        The most popular distros already patched it days ago and others are currently in testing.

        Redhat patched it 2 days ago [redhat.com].
        Ubuntu patched it 2 days ago [launchpad.net].
        Fedora is currently testing the patches [spinics.net]. Not sure if it's already live.
        Debian Lenny has patched it [debian.org].

        • by _Sprocket_ (42527)

          Race?

          The most popular distros already patched it days ago and others are currently in testing.

          Yes, race. All that is part of it. But that doesn't put the kernal live on any given system. I have to take that step. And, depending on your environment, that may require a bunch of other operational steps.

          I'm not making a comment on the difficulty of doing any of this (it tends to be quick and painless in most situations). I'm noting that this is, in fact, news. There IS something to see here. People who are in the position to update a kernal should know about this and know to push it (if they have

        • Isn't it patched in 2.6.35.2? If so, then:

          http://www.archlinux.org/packages/core/i686/kernel26/ [archlinux.org]

          And:

          http://packages.gentoo.org/category/sys-kernel [gentoo.org]

        • And Gentoo is issuing a patch to reconfigure the electrons that will be used by the emerge process.
    • by Americano (920576) on Thursday August 19, 2010 @06:18PM (#33308174)

      Nothing to see here? Will you say the same thing when Microsoft waits 6 years to apply a fix to WinXP? :)

      Yes, these things are less likely to happen with Linux. That doesn't mean Linux kernel processes are above reproach, and can't be made more responsive & accountable in cases like this where somebody obviously dropped the ball on merging a patch somewhere. I hope they spend a little time reviewing how this got missed, to make sure it's not a flaw in their process that could allow it to happen again.

    • by gmuslera (3436)
      Still is something to see there, at least for a few days till maintained distributions push that patch to their kernels and pushes them to the people that keep doing security updates. And for old, running unmaintained distributions servers, could be a bit more complicated. Still, this is a local vulnerability, and not exactly trivial to exploit.
    • by Beelzebud (1361137) on Thursday August 19, 2010 @06:29PM (#33308282)
      "Nothing to see here....." says Lt. Frank Drebin, as the fireworks factory behind him burns to the ground.
    • Compare to Apple... (Score:3, Interesting)

      by Myria (562655)

      Compare this to Apple, which still hasn't fixed my Darwin kernel ring 0 exploit, which I reported in June.

      It's x86-only, so no, it can't be used for the second step of an iPhone jailbreak. =(

      • by Americano (920576)

        By my calculations, this means they've taken 2.5 months, which means they're about 5 years, 9.5 months ahead of schedule if they follow the 6 year benchmark set by the Linux kernel.

        What's the problem? They've got plenty of time!

  • Tuesday (Score:2, Funny)

    by dandart (1274360)
    At least we don't have to wait for four Tuesdays' time for the fix...

    You're holding it wrong.
  • Amazing that SUSE fixed this in it's distro. In the proprietary world they'd still be waiting for the OS maker to fix it. SUSE just fixed it themselves. Many windows bugs could have been fixed but yet remained waiting for years until MS got around to it.
  • by LingNoi (1066278) on Thursday August 19, 2010 @11:11PM (#33310162)

    So I read the PDF...

    The Linux kernel versions that include the commit 320b2b8de12698082609ebbc1a17165727f4c893 from Linus tree are fixed.

    which is the patch.. "Patch "mm: keep a guard page below a grow-down stack segment" has been added to the 2.6.32-stable tree"

    and meanwhile my ubuntu update managaer pops up and shows an update for the kernel and gives the following link to the changelog...
    http://launchpad.net/ubuntu/+source/linux/2.6.32-24.41/+changelog [launchpad.net]

    * mm: keep a guard page below a grow-down stack segment - CVE-2010-2240

    Nice to see people are on the ball with security updates, even if it shouldn't have been happened in the first place.

  • by Pete Venkman (1659965) on Friday August 20, 2010 @03:24AM (#33311204) Journal

    This won't be a problem for me since I don't run Linux.

    Now the shoe's on the other foot!

  • Suse developers suggested a fix for this vulnerability six years ago http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-09/7904.html [derkeiler.com] however for reasons unknown it wasn't noticed or merged.
  • It's funny to see the windows people taking such satisfaction in Linux bugs and completely disregard the time it takes from disclosure to a fix is available. Usually I've already installed the fixed version before I read about it on slashdot. It's just a matter of subscribing to my distro's security announcement mailinglist and upgrade if I run the affected software.
    So in most cases, when i read about bad bugs in Linux it's 'old news'.

    (Blatantly ignoring the six years it took to actually get the fix in

In 1869 the waffle iron was invented for people who had wrinkled waffles.

Working...