Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Bug Security SuSE Linux IT

Root Privileges Through Linux Kernel Bug 131

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 @04: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 valeo.de ( 1853046 ) on Thursday August 19, 2010 @04:50PM (#33307886) Homepage
    No, just that this particular bug has been patched in SUSE for six years, while mainline has only just gotten the fix.
  • by interfecio ( 1023595 ) on Thursday August 19, 2010 @04: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 lortho ( 700090 ) on Thursday August 19, 2010 @05: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.
  • Re:Wait... what? (Score:3, Informative)

    by Short Circuit ( 52384 ) <mikemol@gmail.com> on Thursday August 19, 2010 @05:16PM (#33308136) Homepage Journal

    If I read the git patch correctly, if said root process has a memory-mapped page coincident with a non-root process, and the non-root process can write to said memory mapped region (via having it memory mapped into their own process), then said non-root process can affect the behavior of the root process.

    What was broken, and appears to have been corrected, is that an application's *stack* could grow into a memory-mapped page and corrupt the data in the root process while it's at it. (The stack is a piece of memory that hold data about the functions currently executing in a particular thread in your program.)

    (enter educated guess section; I spend most of my time coding userland apps on Windows, not Linux.)

    The case where this seems most possible to exploit is the loading of shared libraries. I don't know if the same mmap mechanism is used by the kernel, though. While it's entirely probable that writing to that region is protected, so long as the application is doing so under its own memory privilege level, it's possible that there's a syscall into the kernel that expands a thread's stack when the allocated memory for that stack is nearly exhausted. The syscall's operations run with kernel privileges, and it looks like the stack page allocator wasn't sufficiently checking the properties of the userland address it was allocating stack into.

    (end educated guess section; I'm probably wrong, anyway.)

  • Re:Wait... what? (Score:5, Informative)

    by mandelbr0t ( 1015855 ) on Thursday August 19, 2010 @05:25PM (#33308248) Journal

    Actually, no, this is a simple Stack Buffer Overflow. Basically, by causing a running privileged process (e.g. X Server) to make a recursive call, the stack will grow into memory space owned by the unprivileged user. Now, all the unprivileged user has to do is put some code somewhere (perhaps by exploiting another buffer overflow) and rewrite the return address, which lives in its memory page.

    The fix adds a guard page between the shared memory region and the system stack to protect against the stack growing into memory where it is no longer protected. At any rate, ProPolice would have prevented this mistake from being exploitable.

  • by alanebro ( 1808492 ) on Thursday August 19, 2010 @06:09PM (#33308624)
    Cut my post too short.

    "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"
  • by Peach Rings ( 1782482 ) on Thursday August 19, 2010 @07:09PM (#33309088) Homepage

    Also if you read linus's patch notes [kernel.org] they're the exact same problem.

  • by Zero__Kelvin ( 151819 ) on Thursday August 19, 2010 @08:14PM (#33309528) Homepage

    "I've seen many similar statements, so there may be some truth to this, but my experience is that they give you a short-as-possible only-most-relevant question such as "Can you bisect?" or reply like "Patch rejected: missing signoff". It appears their time is very valuable or they have to pay $5 pr. typed letter"

    Behold the phenomenal power off Open Source! The time of each and every kernel developer is in fact a highly valuable commodity, yet I get the benefit of the fruits of their labor without shelling out a sixpence! And the best part? This was fixed last week [kernel.org].

  • by Target Practice ( 79470 ) on Thursday August 19, 2010 @09:00PM (#33309802)

    It's not, but the Linux kernel is... and that's where the vulnerability is...

  • by LingNoi ( 1066278 ) on Thursday August 19, 2010 @10: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 LingNoi ( 1066278 ) on Thursday August 19, 2010 @10:24PM (#33310212)


    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 Chirs ( 87576 ) on Friday August 20, 2010 @01: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.

  • by rolfc ( 842110 ) on Friday August 20, 2010 @02:42AM (#33311278) Homepage

    Yes, something is seriously wrong with this comparison. You compare a clean and unused operatingsystem with a fullfledged Linuxdistribution with a lot of applications.

    Of course the Linuxdistribution will have more bugs, but you dont have to install all the software that comes with it. On the other hand, to be able to use the Windows server to something useful, you have to install more Microsoft and/or thirdparty software. It isnt even a webserver without installing more software in Secunias statistics. IIS has its own category.

    Dont compare apples and pears, you will only fool yourself.

  • by bjourne ( 1034822 ) on Friday August 20, 2010 @05:02AM (#33311802) Homepage Journal

    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.

"May your future be limited only by your dreams." -- Christa McAuliffe