Slashdot Mirror
How To Exploit NULL Pointers
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.)"
TFA is an extremely well-written, easy-to-follow tutorial. I "played along at home" (well, at work, actually) as the author recommended and exploited a system on the first try. Great stuff!
Hang on, one of our SysAdmins wants to talk to me about something.
BRB
What a bad attempt at trolling. You could make various funny posts involving Windows and security, and this is what you came up with? Up your game, mister.
"Ever wondered what was so bad about NULL pointer exceptions?..."
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
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.
Terrorist, bomb, al Qaeda, nuclear, yellowcake, kill, assassinate. Carnivore is dead... long live Echelon.
I was intrigued by the ./ posting, which claimed that the tutorial would show how to exploit any NULL pointer dereference. The actual article, however, requires a CALL to the NULL pointer. While some NULL pointer bugs are function pointers, many are not. Kernel code that merely reads or writes data to a NULL pointer will not be exploitable as shown.
from the article
I thought the BigMem kernel patches a few years back put the kernel in it's own VM, with minimal copying into userspace VM space, or am i missing something?
To be honest, I'm not sure why I bothered writing this comment. If the editors themselves don't care about the accuracy of the stories, why should I?
Be the change you want to see in the world.
It turns out that switching between address spaces is relatively expensive, and so to save on switching address spaces, the kernel is actually mapped into every process's address space, and the kernel just runs in the address space of whichever process was last executing.
So a CPU design bug propagated its way into OS architecture, leading to a security hole.
Intel never really got the crossing of privilege domains right. Context switching is too slow, call gates aren't very useful, and the segmented memory architecture in the 32-bit machines never really caught on. Yet domain-crossing is one of the most likely places for security holes.
For further context, see my whitepaper on how to turn any kdawson-posted Slashdot story into a NULL issue.
Does anyone remember sending a link in AIM as file:||null\null\null? does null points?
Of all the things I've lost; I miss my mind the most. - Mark Twain
You're gonna blow the best source of income some folks have. Nothing like an OS its operator thinks is "secure"....
"Remember when I said I would never lie? Well, that was the first time."
Well, I upped my game. Now up yours.
One of the many exploits that we've used to own the Wii (in fact, the very first runtime IOS exploit that we used, which I found and implemented) was a NULL pointer dereference bug, and it wasn't even a function pointer.
I wrote a detailed blog post about it recently. The short version is that they doubly dereference a near-NULL address and write to it, and NULL happens to be real physical memory that we control (call it 'insecure', if you wil). The double dereference lets us direct the write anywhere, including the stack, and it's game over. That's the "usermode" exploit. Privilege escalation into the kernel is trivial because they have some huge kernel holes. The fact that they map the 'insecure' memory as executable (!) in every application makes it even easier.
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!!!!
I was intrigued by the ./ posting, which claimed that the tutorial would show how to exploit any NULL pointer dereference.
Actually, it claimed that the tutorial would show how to exploit any NULL pointer. Yes, that's right, using a NULL to mean "no object here" is automatically insecure no matter how carefully you check before using it.
If you have a bug in kernel code that causes NULL pointer dereference, it can be used for various nastiness (in this case, privilege escalation).
This is why kernel shouldn't do it, and this is why it was an actual kernel bug that was exploited by so-called NULL pointer exploits. This is why those bugs were fixed.
Apparently some readers have an impression that what was posted is an actual exploit that works on a current kernel by dereferencing NULL pointer in userspace. In reality it relies on a buggy module being introduced, so kernel NULL dereference can be triggered by the user.
Contrary to the popular belief, there indeed is no God.
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.
Sorry, but if anything that simple can cause root access, then that’s a general error of the architecture and kernel. An OS should expect every app and every data input source to cause maximum mayhem in the system. And start from that point.
On in other words: Get SElinux, or an equivalent system (RSbac+more?)!
Any sufficiently advanced intelligence is indistinguishable from stupidity.
get a null pointer to exploit ME
ooooohhhhhhhh
Read radical news here
rats, doesn't work. you guys lie.
if this is supposed to be a new economy, how come they still want my old fashioned money?
[place your favourite code here]
Actually it did work. It's just that root didn't have any money.
The Tao of math: The numbers you can count are not the real numbers.
So under normal circumstances, even with a NULL dereference in the running kernel, this method would not allow you to gain root privileges.
My question is, what legitimate reason might there be for a system to allow applications to map the NULL pointer? Is there a class or role of machines where this might be expected to work?
I tried to up my game, but instead I just lost it.
Directly writing data to a NULL pointer is not enough for an exploit, but if the NULL pointer is to a struct which contains a second pointer, and it modifies what lies behind that pointer-- rather common-- it's not too hard to own the kernel.
This is not "how to exploit NULL pointers" ... this is "how to exploit a kernel NULL function pointer".
Well, duh.
In other news, security researches find exploit for systems with blank root password.
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
The concept of a null pointer kernel vulnerability works in Windows too.
Like Linux, the NT kernel exists in the same address space as applications, so the same concepts apply. To map the null 64k of address space as valid memory, call either VirtualAlloc or MapViewOfFileEx (*). Passing NULL as your desired mapping address to these functions normally means that you want Windows to find an available virtual address for you. To get around that, pass (void*)1. This works because NT will round down to the nearest allocation boundary (64k for new allocations).
* The real system calls are actually NtAllocateVirtualMemory and NtMapViewOfSection, respectively.
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
I was intrigued by the ./ posting, which claimed that the tutorial would show how to exploit any NULL pointer dereference. The actual article, however, requires a CALL to the NULL pointer. While some NULL pointer bugs are function pointers, many are not. Kernel code that merely reads or writes data to a NULL pointer will not be exploitable as shown.
But sometimes, they can still be exploited. Let's hypothesize a UNIX clone whose kernel has this code in its implementation of the chroot() system call, something that only root should be able to call:
if (get_current_process()->m_uid != 0)
{
return EPERM;
}
Now let's suppose that there is a bug in the kernel that you can exploit to cause get_current_process() to return a null process pointer. Using mmap(), you can allocate the zero page. The get_current_process()->m_uid expression now reads memory that you control. Of course, you're going to put 0 at that location.
With chroot() available to a non-root program, it will only be a matter of a few tricks with setuid programs before you get root access. Once you have root access, you can elevate to full kernel mode by loading a kernel extension.
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
Here is one example how to exploit a different kind of NULL pointer dereference.
The article is rather long, but the short summary is, the kernel does a->some_field->x=NULL , where a is the NULL pointer.
The NULL page is under the control of the exploiter. So he can set some_field to point to a memory location he wants to zero out. That could be any location in kernel space (such as a hypothetical byte that contains the user id of the current process). In our case, the exploiter used the return address on the stack. Which caused the system call to "return" to address NULL, nicely transforming a "write to NULL" exploit into a "call NULL exploit", and from there, we continue just like in the tutorial.
...as far as I can tell is simply to ban null pointers in the kernel.
I've done alot of development in my time and I've never needed to point at null.
Function pointers are very different from a NULL reference to data.
A sysadmin need to understand that before they cry wolf like this. Accessing a null data pointer will crash a program if they aren't catching all exceptions. When I get a null pointer, it means something is really really wrong so I'll shutdown the program. Inside the kernel, I hope a kernel panic occurs. I think this is better than having a random value in a pointer because someone didn't initialize it to NULL or reset it to NULL once the memory is free()'ed.
As to null function pointers - well, I always check that those have a non-null value before using them, since I initialize all pointers to NULL, even function pointers. When the .so or .dll using them is removed from RAM, I'll reset them to NULL and be golden again.
People that don't KNOW pointers should be allowed to use them. C# isn't a good tool to learn about pointers.
FFFFFFFFFFUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU dummy text to bypass filter this is just redundant text inserted to bypass filter
The correct term is null pointer (no all-caps). It's a combination of the words null and pointer. In the C and C++ languages, a few of the standard headers define a macro named NULL to a value that can be used as a null pointer in those languages.
On a related note, I sometimes see people talking about a MACRO. Same thing, the word is macro, and there's a common convention of naming macros in all-caps; the term macro itself shouldn't be in all-caps. Same goes for camel case and all-caps; even though these refer to fooBar and FOOBAR, the terms themselves aren't written that way, otherwise the word invisible would have to be written as , and the word enormous would have to be written as... well, I don't have enough room to write it as big as it would need to be.
ftfy
The original Multics design for virtual memory and dynamic linking & loading, from which Unix and Linux derive, relied on pointer fault handling to distinguish different stages of linking. People already understood these vulnerabilities in the 1950s, folks. We should regard this crap as ancient history because we could be standing on the shoulders of giants, if only a generation of know-nothings (Gates, I'm looking at *you*) hadn't blithely ignored most of the lessons already learned.
The article was trying to show a simple example.
I think a far more common exploit would be to place a copy of a structure the kernel expects to reference at 0 and trigger some bug so it uses a null pointer to such a structure. If that structure contains a pointer to a function that the kernel calls you put the pointer to your code there. Probably more likely the structure just contains a pointer to some location the kernel will write, you change this to point at something in the kernel you want to overwrite, and also work on getting the kernel to write exactly the data you want. After it does that you have patched the kernel to do your bidding.
One thing I think is very misleading is that the title should be changed to read "use of a NULL pointer *BY THE KERNEL* can be exploited". To the casual observer this sounds like NULL pointers in user programs are dangerous.
The summary is a bit broad. TFA is good, but is limited to cases where you can exploit a weakness to get a page mapped at address 0 and then exploit another kernel bug to get it to call to address 0 (not simply read or write). IF you can manage that and IF you know exactly where things are in the running kernel, THEN you have a root exploit. That's not to say it isn't a problem, just that it's far from ANY NULL pointer dereference.
Educate one more hacker how to exploit systems... Where as this is very interesting to know, and free speech is the key to our society, how much good has this accomplished? The least anyone could do is leave this particular aspect up to an individual to figure out, like giving a loaded gun to a crazy person. Is it just me or does anyone else think about the consequences of these things...