Slashdot Mirror


Local Privilege Escalation On All Linux Kernels

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

21 of 595 comments (clear)

  1. I don't get it... by Anonymous Coward · · Score: 5, Interesting

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

  2. Re:Security through Obscurity? by TheRealMindChild · · Score: 3, Interesting

    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.

    --

    "When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
  3. SELinux? by Shimdaddy · · Score: 2, Interesting

    Is this something that SELinux would protect against?

  4. World-wide Linux reboot party by adosch · · Score: 2, Interesting

    Oh how I wish 'ksplice' was more widely adopted in my deployed distro at work...

  5. Guys? by eexaa · · Score: 4, Interesting

    where's the source?! I want to try it. On my box.

  6. Re:Security through Obscurity? by molo · · Score: 3, Interesting

    Important, not "Critical". And there are a bunch like that on every Patch Tuesday,

    -molo

    --
    Using your sig line to advertise for friends is lame.
  7. Re:Security through Obscurity? by DavidTC · · Score: 4, Interesting

    Yes, but generally exploits get discovered by others if they are used.

    At some point, someone curious will get hacked, and wonder how the hell that happened, and track down the exploit.

    And that's not even including discovery on the cracker's side. (People he works with, etc.)

    The only way to keep an exploit a secret is to (almost) never use it. It's going to be made public within a few months of even low usage.

    --
    If corporations are people, aren't stockholders guilty of slavery?
  8. Re:Security through Obscurity? by spun · · Score: 5, Interesting

    No. If nobody knew it wasn't a security issue. I'm sure there are bugs on every OS with more than 8 years old yet to discover.

    You veered completely off track right about here: "If nobody knew"

    Seriously? Really, that's the best you could come up with? That's your apologia? How do you know nobody knew? You think the real blackhats are going publicizing their 'sploits? Blackhats these days aren't script kiddies and honest hackers, they are hard core Russian mafia doing it for cash. Your Linux systems could have been owned twelve ways from Sunday for EIGHT YEARS without you ever knowing it, and you are claiming 'it wasn't a security issue?' WTF? When did Linux get infested with idiot fanboys? Shouldn't you be slobbing all over an Apple or something? I was using Linux before you even knew what Unix was, I despise Microsoft and love open source, but a bug is a bug.

    Try this one: 'No. Because it's a freaking LOCAL EXPLOIT and nearly no-one uses Linux for multi-user systems now that everyone can afford their OWN FREAKING COMPUTER.' Good lord, kids these days, gotta teach them everything.

    --
    - None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
  9. Re:pwned by gmuslera · · Score: 4, Interesting

    If this was Windows we'd never hear the beginning of it. How much local privilege escalation vulnerabilities normal windows users worry about? Are the remote vulnerabilities (and the ones that don't need to escalate, as run as the current user) the ones that get lots of publicity. And you got from time to time a number big enough of remote vulnerabilities there to consider them the only ones that matters.

    Of course, if you add a local privilege escalation to a some app remote vulnerability that enables to run code, even if is with low privileges, there you have a potential remote root exploit. Is something to care about, but odds are low that a lot of systems will be affected.

  10. Re:Security through Obscurity? by taviso · · Score: 3, Interesting

    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);

    --
    ex$$
  11. Vulnerable by design by 0xABADC0DA · · Score: 5, Interesting

    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.

    1. Re:Vulnerable by design by Anonymous Coward · · Score: 1, Interesting

      PaX does NOT protect against this type problem; the kernel can still jump into code mapped by the application.

      PaX can prevent particular instances of this type of problem, like a NULL page attack, but in general it does not. You can still get code loaded at arbitrary addresses, so a kernel bug can still cause it to jump into an application's code. You just have to be slightly creative to do it.

      To reiterate, this is an entire class of problems, where the kernel jumps into user process code, and the only real protection in linux is to completely separate the kernel and process memory spaces (there are kernel config options that do this), at a huge price in terms of performance.

  12. Re:It's from April? Really? by Anonymous Coward · · Score: 0, Interesting

    Posting anonymously for a reason... I knew about it 3-4 years ago. I discovered it disassembling some hack/crack code and verified it against the kernel sources. I used it myself quite a bit before changing careers. I know slashdot doesn't want to hear it, but having access to the source code helps find and verify root exploits.

  13. Re:Some distros less vulnerable by default by iggymanz · · Score: 2, Interesting

    on my Debian 5 (Lenny ) it's zero

  14. Re:Security through Obscurity? by Grishnakh · · Score: 2, Interesting

    Is this like some kind of (biological) virus that might just be out there, wreaking havoc and killing people, even though there's absolutely no evidence of such a virus? That makes no sense at all.

    If this exploit were already known by people with malintent, they would have used it already, and it would be known more widely. Note that this works for both open-source and closed-source code. The main advantage with open-source code is that anyone can look through the code for problems; this doesn't mean that they do. But it looks like this exploit was found by some researchers, not the kernel developers. This is something that can't be done in the closed-source world, so theoretically there should be fewer exploits in OSS code overall.

    In reality, however, I think the issue of closed-source vs. open-source really doesn't make that much difference when it comes to security. What does make a huge difference is Microsoft's crappy code and architecture, with idiotic things like ActiveX. OSS code would have the same problems if their developers made such poor choices; it's just that OSS coders aren't driven by marketing the way MS (and other proprietary companies) is, forcing them to make poor architectural choices because marketing thinks customers will like it better.

  15. Re:Security through Obscurity? by martyros · · Score: 2, Interesting

    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. Presumably the seriousness of this NULL pointer exploit inspired others to look for exploitable NULL pointer bugs as well.

    --

    TCP: Why the Internet is full of SYN.

  16. Re:Some distros less vulnerable by default by gfolkert · · Score: 2, Interesting

    Debian Sid running:

    greg@maxime:~ [0] $ uname -a
    Linux maxime 2.6.31-rc4-686-bigmem #1 SMP Sat Aug 1 08:00:47 UTC 2009 i686 GNU/Linux
    greg@maxime:~ [0] $ cd /proc/sys/vm/
    greg@maxime:/proc/sys/vm [0] $ cat mmap_min_addr
    4096

    How is that?

    --
    greg, REMEMBER ED CURRY!!!
  17. Re:Security through Obscurity? by Anonymous Coward · · Score: 1, Interesting

    The thing you're missing is that the kernel normally runs with a super-set of its own memory mappings and the user's memory mappings (so for instance if you call write(fd, buf, 100) it can read the data "buf" points to)

    Typically NULL will always be an unmapped page but the user can manually map something there if they want... this is true on UNIX or windows (see taviso's comment above for the details) Newer linux kernels actually have a setting to prevent this (refusing to allow the user to map addresses 64K) but it breaks some programs.

    So the exploiting program maps code at page zero, then causes the NULL dereference. Instead of kernel fault you'd expect, you get an exploit.

  18. Re:Security through Obscurity? by Anonymous Coward · · Score: 1, Interesting

    well, the problem is, the blackhats don't bother with the source to find holes most of the time, it is too annoying (well, I sure hope, but I am sure we still have a few morons that check in code following the obvious patterns that people look for to root out uninitialized data use, not to mention whomever receives the Covery scanner reports and sit on them instead of immediately patching them all or forwarding them to people who would).

    Instead, you use automated fuzzing tools to attack the syscalls, network layer, etc. And guess what, those techniques work just as well in *ANY* OS, from Windows, to Cisco's IOS. when a syscall crashes in nice ways, you can look at the source, or you can just look at the crash dump to find out what was derreferenced, poison it, and profit. It is that simple.

    So the added damage done because they can easily see inside is very little.

  19. Re:Security through Obscurity? by Bent+Mind · · Score: 4, Interesting
    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.

    --
    Request a Linux Shockwave player here: http://www.macromedia.com/support/email/wishform/
  20. Re:Ahh... by pugugly · · Score: 2, Interesting

    The problem is, if this were an eight year old really bad exploit in Windows, the article would be explaining how the authors pointed this out to Microsoft 7 years and six months ago, were threatened with legal hell if they said anything to anyone, the exploit has been in the wild though three versions of windows for six years, they finally managed to get a gag order revoked now, and we're just now finding out about it.

    Instead we are finding out about an old, but only just uncovered (by white hat) exploit, and there is a reasonable chance my PC will be patched by the time I get home tonight.

    A 'bias' or 'prejudice' is judging in advance of the facts. When a judgment is based on a long prior history, the term is 'Experience'.

    Pug

    --
    An Invisible Entity of Vast Power whose existence must be taken on faith alone: Liberal Media