Forgot your password?
typodupeerror
Security Software Linux IT

Local Privilege Escalation On All Linux Kernels 595

Posted by timothy
from the uriah-deems-it-scary dept.
QuesarVII writes "Tavis Ormandy and Julien Tinnes have discovered a severe security flaw in all 2.4 and 2.6 kernels since 2001 on all architectures. 'Since it leads to the kernel executing code at NULL, the vulnerability is as trivial as it can get to exploit: an attacker can just put code in the first page that will get executed with kernel privileges.'"
This discussion has been archived. No new comments can be posted.

Local Privilege Escalation On All Linux Kernels

Comments Filter:
  • Ahh... (Score:5, Funny)

    by clone53421 (1310749) on Thursday August 13, 2009 @04:31PM (#29057105) Journal

    So that's what the NULL pointers were for.

  • I'm safe! (Score:5, Funny)

    by Anonymous Coward on Thursday August 13, 2009 @04:31PM (#29057121)

    I use Windows!

  • by MarkvW (1037596) on Thursday August 13, 2009 @04:35PM (#29057175)

    Does this mean that Linux was never more secure than Windows--only more obscure?

    • by TheRealMindChild (743925) on Thursday August 13, 2009 @04:40PM (#29057281) Homepage Journal
      Well, all Microsoft OS's would fault when trying to execute code at a NULL address, merely because people needed to use something to signify an uninitialized pointer. Most operating systems do this. Apparently (I could be wrong, the article is short on details and I don't play in that part of the kernel), this is due to an optimization and not necessarily the original intention.
      • by taviso (566920) on Thursday August 13, 2009 @05:32PM (#29058125) Homepage

        Actually, it is possible to map at NULL in Windows, which is just as plagued by NULL pointer dereferences as Linux is.

        Try this:

        BaseAddress = (PVOID) 0x00000001; // (1 & ~PAGE_SIZE) == NULL
        RegionSize = 0x1000;
        NtAllocateVirtualMemory(GetCurrentProcess(), &BaseAddress, 0, &RegionSize, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);

      • Re: (Score:3, Interesting)

        by martyros (588782)
        It turns out that it's not simple to map NULL, but unfortunately (from a security standpoint) not impossible. It's normally disallowed, but since there are programs that sometimes need it (namely domemu-style programs). See this LWN article describing the previous NULL-dereference exploit [lwn.net]. Presumably the seriousness of this NULL pointer exploit inspired others to look for exploitable NULL pointer bugs as well.
      • by Bent Mind (853241) on Thursday August 13, 2009 @11:27PM (#29061539)
        About a week ago, I updated to kernel 2.6.30. One of the options that showed up describes itself thus:

        CONFIG_DEFAULT_MMAP_MIN_ADDR: This is the portion of low virtual memory which should be protected from userspace allocation. Keeping a user from writing to low pages can help reduce the impact of kernel NULL pointer bugs.

        Unless I am misunderstanding, or the bug is in this code, the Linux kernel is already protected if properly configured. The kernel already prevents this attack.

    • Re: (Score:3, Insightful)

      by dissy (172727)

      Does this mean that Linux was never more secure than Windows--only more obscure?

      It's hardly obscure since they could look and find it, evidenced by the fact they found it.

      Go try that with the Windows kernels!

      In addition, there is already a patch out for this, which by end of the week will be pushed down from the distro managers. We don't have to wait years after finding it for the fix to be released, as Microsoft historically does.

      In fact, why just assume this similar bug is NOT in the windows kernel? Did you check? Did any reputable security company check?
      I'm not saying it is there

      • by recoiledsnake (879048) on Thursday August 13, 2009 @05:14PM (#29057843)

        Does this mean that Linux was never more secure than Windows--only more obscure?

        It's hardly obscure since they could look and find it, evidenced by the fact they found it.

        Go try that with the Windows kernels!

        In addition, there is already a patch out for this, which by end of the week will be pushed down from the distro managers. We don't have to wait years after finding it for the fix to be released, as Microsoft historically does.

        In fact, why just assume this similar bug is NOT in the windows kernel? Did you check? Did any reputable security company check?
        I'm not saying it is there, only that you can't easily prove otherwise.

        *that* is the security being spoken of.

        As far as I know, only one OS claims no exploits, and that is OpenBSD.

        The transparent thing works both ways... it's easier for black hats to find holes too, by your own logic. And they can keep it secret and exploit it as long as they can. A similar bug existing in Windows doesn't prove anything and is irrelevant here. After all 'M$ can't code shit'. Linux and FOSS is commonly claimed to be more secure because of it's development model and bug free here in these parts. Any data that runs counter to this is routinely downplayed by commenters and moderators... just like your post got modded up.

        • by freeweed (309734) on Thursday August 13, 2009 @05:22PM (#29057955)

          Your post got modded up, too.

        • by Vexorian (959249) on Thursday August 13, 2009 @05:41PM (#29058257)
          It was fixed much faster than MS after it was announced. I guess it is 100000 times faster than your usual MS flaw. So, yeah Linux is more secure.

          Also, did you bother reading what this exploit does? It is very bad because it allows user programs to gain administrator privileges. This is insecure because it puts Linux in a category that's as insecure as all pre-vista windows computers and also the UAC-enabled-because-else-it-is-useless vista and 7 computers. That's the problem here, it moves Linux to a windows state...

          Finally, it is easier to find flaws in Linux, this increases the chances blackhats found bugs, but it also increases the chances someone else will find it in paralel, preventing your hypothetical situation...

          Ironically, it is because of some artificial obscurity that this bug was present and took so long to find. Most vulnerabilities aren't caused by obscure optimization issues, and are findable in source code, those were a non-issue thanks to the lack of obscurity. So this actually proves obscurity != security.

    • by amorsen (7485) <benny+slashdot@amorsen.dk> on Thursday August 13, 2009 @04:44PM (#29057349)

      Generally people don't care about local privilege escalation on Windows. Like this vulnerability [microsoft.com].

      • Re: (Score:3, Insightful)

        by recoiledsnake (879048)

        Linux runs on a lot of shell servers, gameservers, webhosts etc. where normal user accounts are sold to customers. This happens much less with Windows servers which tend to be more owned and used by a single entity with full admin rights.

  • I don't get it... (Score:5, Interesting)

    by Anonymous Coward on Thursday August 13, 2009 @04:36PM (#29057205)

    Why the bloody hell isn't page 0 hard-wired to panic the kernel / SIGSEGV the userland when accessed?

  • by Anonymous Coward on Thursday August 13, 2009 @04:36PM (#29057209)

    Here's the real one- linked from (mostly) useless article.
    http://archives.neohapsis.com/archives/fulldisclosure/2009-08/0174.html [neohapsis.com]

  • by thenextstevejobs (1586847) on Thursday August 13, 2009 @04:37PM (#29057219)
    Or I would be able to, if there were any
  • (from the blog) (Score:5, Informative)

    by An anonymous Frank (559486) <frank@harryst o t le.com> on Thursday August 13, 2009 @04:40PM (#29057277) Homepage

    In the Linux kernel, each socket has an associated struct of operations
    called proto_ops which contain pointers to functions implementing various
    features, such as accept, bind, shutdown, and so on.
    If an operation on a particular socket is unimplemented, they are expected
    to point the associated function pointer to predefined stubs, for example if
    the "accept" operation is undefined it would point to sock_no_accept(). However,
    we have found that this is not always the case and some of these pointers are
    left uninitialized.
    This is not always a security issue, as the kernel validates the pointers at
    the call site, such as this example from sock_splice_read:
    [snip]
    But we have found an example where this is not the case; the sock_sendpage()
    routine does not validate the function pointer is valid before dereferencing
    it, and therefore relies on the correct initialization of the proto_ops
    structure.
    We have identified several examples where the initialization is incomplete:
    [snip]

  • by sofar (317980) on Thursday August 13, 2009 @04:40PM (#29057283) Homepage

    sudo

    Please, this is a _local_ privilege escalation. It's not like code red infecting your box remotely. A sledgehammer is also a local privilege escalation.

    • by jandrese (485) <kensama@vt.edu> on Thursday August 13, 2009 @04:59PM (#29057579) Homepage Journal
      The thing is, local privilege escalations can become remote privilege escalations when combined with buggy services that allow for code injection. This is especially bad for people who are forced to run services that they don't trust and thus place them in jails, only to discover that if the exploit happens at the kernel level then your jail means nothing.

      My guess is that rootkits are being updated as we speak, so get your kernels patched people.
      • Re: (Score:3, Insightful)

        by cenc (1310167)

        This is easily used as a remote exploit from the looks of it. Someone correct me if I am wrong here. Some of the new linux users are likly getting the impression you need to be physically sitting at the machine.

        Say you have virtual server somewhere as is common to most low end VPS hosting companies with linux running on it with a reseller account. What is there a few million of these or more around the World likly?

        You have given clients ssh access to use sftp. So, they have limited local user rights, if the

    • by athakur999 (44340) on Thursday August 13, 2009 @05:08PM (#29057737) Journal

      But if you have any programs that access the Internet that have a bug that allow running arbitrary code, couldn't a remote cracker could exploit the vulnerability in that program to invoke this bug, and through that gain root access to the machine? It sounds like the program being exploited could even be running as a regular user.

    • by quarterbuck (1268694) on Thursday August 13, 2009 @05:09PM (#29057757)
      A sledgehammer is a Denial of Service - Unless you aim it at the head of the operator and threaten to use it.
  • SELinux? (Score:3, Interesting)

    by Shimdaddy (898354) on Thursday August 13, 2009 @04:41PM (#29057287) Homepage
    Is this something that SELinux would protect against?
  • Guys? (Score:4, Interesting)

    by eexaa (1252378) on Thursday August 13, 2009 @04:55PM (#29057515) Homepage
    where's the source?! I want to try it. On my box.
  • by Bandman (86149) <bandman@gmail . c om> on Thursday August 13, 2009 @05:19PM (#29057915) Homepage

    From http://archives.neohapsis.com/archives/fulldisclosure/2009-08/0174.html [neohapsis.com]:

    -------------------
    Mitigation
    -----------------------
    Recent kernels with mmap_min_addr support may prevent exploitation if
    the sysctl vm.mmap_min_addr is set above zero. However, administrators
    should be aware that LSM based mandatory access control systems, such
    as SELinux, may alter this functionality.
    It should also be noted that all kernels up to 2.6.30.2 are vulnerable to
    published attacks against mmap_min_addr.

    I have checked my default Ubuntu and CentOS/RHEL boxes, and both of them are set well above 0:

    root@Ubuntu:/proc/sys/vm# cat mmap_min_addr
    65536

    [root@CentOS /proc/sys/vm] cat mmap_min_addr
    65536

    [root@RHEL /proc/sys/vm] cat mmap_min_addr
    65536

  • by calmofthestorm (1344385) on Thursday August 13, 2009 @05:31PM (#29058103)

    Because we fix it instead of hushing it up until it becomes fairly well known and then waiting a month to fix it.

    That said, it's nice to see the occasional vuln in Linux. Helps shut up the fanbois and keep everybody sharp. Because while under many eyes, all bugs are shallow, that only works if the eyes are actually looking.

    • Eyes Wide Shut (Score:3, Insightful)

      by westlake (615356)

      Because while under many eyes, all bugs are shallow, that only works if the eyes are actually looking.

      For eight long years no one was looking. Tell me again how the geek spins this story in a way that inspires confidence in Linux and FOSS?

  • RHEL is safe? (Score:4, Informative)

    by neurovish (315867) on Thursday August 13, 2009 @05:32PM (#29058121)

    It looks like RHEL's mmap_min_addr (cat /proc/sys/vm/mmap_min_addr) is set to 65536 by default. According to the vulnerability posting:

    Recent kernels with mmap_min_addr support may prevent exploitation if
    the sysctl vm.mmap_min_addr is set above zero. However, administrators
    should be aware that LSM based mandatory access control systems, such
    as SELinux, may alter this functionality.

    So, if you're running stock RHEL 5.3 without SELinux, you should be safe?

  • by Petersko (564140) on Thursday August 13, 2009 @05:36PM (#29058187)
    And from all across the globe came the sound of geeks crying, for they would soon see their beloved "uptime" reset to zero.
  • Vulnerable by design (Score:5, Interesting)

    by 0xABADC0DA (867955) on Thursday August 13, 2009 @05:59PM (#29058529)

    In normal configs, Linux is vulnerable to this kind of problem by design because it runs unsafe programs and then for efficiency the kernel also has direct access to it's memory plus the memory for a process doing a syscall. And it's not just a NULL pointer, and preventing maps for page zero doesn't solve the problem... it just means you need to find a bug where you can corrupt a function pointer to point to mappable space.

    What this demonstrates is that the cost of isolating programs from each other by using separate memory spaces has a much higher cost than commonly understood. It either has a ~10%-20% overhead and is insecure by design (kernel map includes calling process memory space) -or- it is far slower than even that, but safe (kernel memory is completely separate from process). Computers are already faster than many users need... maybe it's finally time for an OS with a single memory space, like JavaOS or jxos, or even Singularity.

    • by True Grit (739797) * <edwcogburnNO@SPAMgmail.com> on Friday August 14, 2009 @12:28AM (#29061947)

      In normal configs, Linux is vulnerable

      The problem you're describing is not an issue just for Linux but most current 'conventional' OSes. On any OS with a shared memory space as you described, if you can a) 'hack' a pointer, and b) move or map your own code to where that 'hacked' pointer is now pointing to, and c) combine this with some other exploit/bug to get elevated privileges in the code you inserted earlier and take immediate advantage of this, then you can theoretically pwn the system whatever its OS (as always, it depends on the specific circumstances).

      As you say, this is fundamentally a weakness of the hardware-assisted approach to process isolation, because in a paradigm that allows modifiable pointers in userland code, neither the hardware nor the OS can ever *really* know what the pointers are actually pointing to.

      It either has a ~10%-20% overhead and is insecure by design (kernel map includes calling process memory space)

      Not sure I'd go as far as 'by design', at the very least its not an easy exploit to accomplish (not withstanding this latest problem), since it depends on finding at least one bug/flaw in the OS to let you do the first step of 'hacking' a pointer (and usually at least one more bug/flaw to be able to do something really dastardly), but yes, there is an overhead, and its certainly not a perfect model (what is?).

      maybe it's finally time for an OS with a single memory space, like JavaOS or jxos, or even Singularity.

      If they can get it right, absolutely.

      In fairness however, these OSes accomplish their goal by restricting you to a type-safe language(s), in effect, they (try to) avoid the problem of pointers being 'hacked' by eliminating the presence of writable/modifiable pointers that *can* be 'hacked' within running code. They use the strictness of the language as the protection mechanism, rather than hardware assistance. This however is not trivially easy to accomplish either (see jxos and their 'Isolates' mechanism they're having to shim into their system), which is why these OSes remain work-in-progress research projects. Then, once they do get it right, we won't be able to just 'port' all our current software over and take off, nope, all the software we use now will have to be rewritten in a type-safe language that that OS supports (or thrown out!), so the switching over process won't happen anytime soon. :(

      It is a 'cool' idea though, if for no other reason than it avoids the overhead of the hardware assisted model, and eliminating modifiable pointers (at the source code level) in code will allow smarter static/jit compilers to safely do *far* more aggressive optimizations than they can do now, as modifiable pointers (especially if they can also be aliased) are the single biggest headache for any optimizing compiler.

  • by synthesizerpatel (1210598) on Thursday August 13, 2009 @08:03PM (#29060065)

    Linux is ready for the desktop!

Work is the crab grass in the lawn of life. -- Schulz

Working...