Local Privilege Escalation On All Linux Kernels 595
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.'"
I don't get it... (Score:5, Interesting)
Why the bloody hell isn't page 0 hard-wired to panic the kernel / SIGSEGV the userland when accessed?
Re:Security through Obscurity? (Score:4, Interesting)
SELinux? (Score:3, Interesting)
Comment removed (Score:2, Interesting)
Guys? (Score:4, Interesting)
Re:Security through Obscurity? (Score:3, Interesting)
Important, not "Critical". And there are a bunch like that on every Patch Tuesday,
-molo
Re:Security through Obscurity? (Score:5, 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.
Re:Security through Obscurity? (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.
Re:pwned (Score:5, Interesting)
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.
Re:Security through Obscurity? (Score:4, 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);
Vulnerable by design (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.
Re:It's from April? Really? (Score:0, Interesting)
Re:Some distros less vulnerable by default (Score:3, Interesting)
on my Debian 5 (Lenny ) it's zero
Re:Security through Obscurity? (Score:3, 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.
Re:Security through Obscurity? (Score:3, Interesting)
Re:Some distros less vulnerable by default (Score:2, Interesting)
Debian Sid running:
greg@maxime:~ [0] $ uname -a /proc/sys/vm/
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
greg@maxime:/proc/sys/vm [0] $ cat mmap_min_addr
4096
How is that?
Re:Vulnerable by design (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.
Re:Security through Obscurity? (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.
Re:Security through Obscurity? (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.
Re:Security through Obscurity? (Score:5, Interesting)
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:Ahh... (Score:3, 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