How To Exploit NULL Pointers 139
An anonymous reader writes "Ever wondered what was so bad about NULL pointer exceptions? An MIT Linux kernel programmer explains how to turn any NULL pointer into a root exploit on Linux. (There was also a previous installment about virtual memory and how to make NULL pointers benign.)"
Exceptons? (Score:5, Informative)
Nothing. Because if they're an exception, they've been safely caught by the platform's exception handling mechanism. This article isn't about exceptions, it's about dereferencing your actual raw NUL pointers themselves in languages that either don't have the exception mechanism or where it simply hasn't been used.
Cheers,
Ian
OS dependent (Score:4, Informative)
This is very OS dependent.
For example, on AIX on POWER, page 0 in both real and virtual addressing modes is readable by all and writable by none. So a read from a NULL pointer produces junk data (actually interrupt machine code) and a write is fatal.
Re:OS dependent (Score:5, Informative)
Sorry to point out the redundancy, but the summary seems clear enough with its how to turn any NULL pointer into a root exploit on Linux .
Re:Bad summary (Score:4, Informative)
The OP's article wasn't very long, so you should be able to figure out that you just rephrased what he said: you need to have a null pointer function call kernel bug to exploit this. No combination of null pointer vulnerabilities in user space, and no null pointer reads and writes in kernel mode (which are more common) will get you root.
Re:Exceptons? (Score:5, Informative)
Besides, the article is actually about NULL pointer dereferences within the kernel, where niceties like language-based exception handling mechanisms are often hard to come by. So the language you write your application code is immaterial.
Also not just any dereference will do, it has to be a function pointer dereference.
And recent kernels have protection against mmap()ing page 0.
However the author has a good point that both NULL function pointer calls in the kernel and hackers getting around the mmap() protection have happened before. So while you can't exactly exploit any Linux system using the procedure he describes (several critical components require you to already have root :P) it does sound like a weakness.
Re:Is the kernel address mapping part still true? (Score:5, Informative)
Yeah, shouldn't switch be easily take care of by a base register?
Well it is. On x86 systems, the intuitively named Control Register 3 is a pointer to the base of the page tables. From a software point of view, switching address spaces is as easy as writing CR3.
From a hardware point of view, that act has additional implications. You have to flush the TLBs, which sucks royal if it happens on every system call. If you have linearly tagged caches (or any other linearly tagged structure) then you'll have to flush those too. There are ways to partially mitigate these effects, but since you can't rely on them being there it's best to just avoid CR3 writes as much as possible -- which means there's less reason to implement the necessary widgets.
Re:Assumes a CALL to the NULL ptr (not any referen (Score:1, Informative)
even better, you need to do some incredibly dumb shit as root first. Next up: if you're logged in as root, su doesn't prompt for a password! security breach!!!!
It assumes that the hacker would be able to find an exploit so that no root would be necessary:
While mmap_min_addr does provide some protection against these exploits, attackers have in the past found numerous ways around this restriction. In a real exploit, an attacker would use one of those or find a new one, but for demonstration purposes it’s easier to just turn it off as root.
Re:The kernel is at fault. (Score:5, Informative)
Sorry, but if anything that simple can cause root access, then that’s a general error of the architecture and kernel.
By default you need root access (or an exploitable bug) to map page zero into your address space, and you need to specifically configure the kernel to allow it, and then you need an exploitable kernel bug to make use of it.
I wouldn't exactly call that 'simple'.
Re:Is the kernel address mapping part still true? (Score:3, Informative)
Why should a change of the page table be needed?
It's not needed if you map your kernel into the application's page tables. ;)
All you need are separate segments for kernel and user mode.
1) Segmentation is essentially non-existent* in 64-bit mode.
2) Segmentation sucks. Always has, always will. That's why even in 32-bit mode most segments are made with base 0 and max limit, and processors are optimized for this case.
3) Okay, so you switch your CS and DS segments when you go into kernel mode (well actually you do anyway, but they're non-base-zero in this case). That's great, but you still need to map your linear address (linear = virtual address + segment base) to a physical address. So you either need to write to CR3 to use the kernel's page table, or you need to map your kernel's memory into the user's page table.
* Ask VmWare about the non-essentially existent remnants of segmentation.
Re:Exceptons? (Score:5, Informative)
But then it is not an exploit, since the kernel always is root anyway.
As given, no the procedure is not a working exploit for any meaningful definition ("I'm teh 1337 hacks-zor! I r00ted my home desktop!")
However, if you could identify a case where the kernel dereferenced a NULL function pointer, and if you could get around the kernel's mmap() protection (neither implausible), then you can get the kernel to run your code using its privilege level. Meaning you can get root for yourself. And then yes indeedy you have an exploit.
Re:Exceptons? (Score:2, Informative)
If there are exploitable bugs in the kernel, then those are the fault in OS security.
Re:Major caveat from another article (Score:1, Informative)
Wine and Dosemu take advantage of it. Also, the decision by the designers of C to make 0 an invalid address is really just a language decision, and has no basis in real hardware. The Linux kernel, however, is written in C, but can't assume the hardware will take care of a NULL dereference. That's really what the problem is. In reality, the bare hardware will allow something like *((int*) 0) = 0xdeadbeef; it's the operating systems job to enforce the rules.
FYI: AMD-V or Intel Nehalem or later (Score:3, Informative)
FYI: AMD-V or Intel Nehalem or later
Nehalem processor TLB address mapping entries include a Virtual Processor Identifier (VPID), while AMD-V supports tagged TLBs.
-- Terry
Re:Exceptons? (Score:3, Informative)
If you had Wine installed in Ubuntu, the package would disable the protection to enable 16-bit Windows apps to run.
Re:kernel null function pointer (Score:3, Informative)
This is not "how to exploit NULL pointers" ... this is "how to exploit a kernel NULL function pointer".
No, it's just the "simplest" example of exploiting NULL pointers. If your NULL pointer is not a function pointer, you can still exploit it in many cases, you just need to work slightly harder [hackmii.com].