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

Comments

Easy and concise

[Lord Grey]

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

Exceptons?

[mccalli]

"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

Re:Exceptons?

[shutdown -p now]

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.

Actually, most JIT-based VMs don't do explicit null checks, but rather let the OS signal access violation (as it is supposed to be guaranteed for NULL pointers, unlike dangling or garbage ones), and if it happens, wrap it into the language-specific exception - it's much faster than explicit checks for every pointer dereference.

Re:Exceptons?

[Chris Burke]

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:Exceptons?

[Chris Burke]

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?

[eparis]

He demonstrates the simplest easiest to understand case, that of a NULL function pointer. But it really can extend to reads and writes of a NULL pointer as well (not always but often). If you can make the kernel read data from a NULL pointer you would be able to trick the kernel into reading a fake struct that you placed at NULL. Maybe that fake struct had a function pointer which you can easily set to another userspace address and voila, win. Maybe the code will read that struct and then write somewhere else in memory based on the information in that struct. Simply make that write happen in a place you choose which might lead to an eventual NULL function pointer.

Any time the kernel accidentally dereferences a pointer (especially one outside of kernel space) and uses that data things can go bad. The mmap_min_addr checks were added to harden against the EXACT class of common bugs he describes and I'm saddened it was dismissed so out of hand.

Bad summary

[ElMiguel]

As usual, bad summary. TFA explains how to exploit a theoretical kernel bug that happens to "read a function pointer from address 0, and then call through it". That's a long shot from turning "any NULL pointer" into a root exploit as the summary claims.

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?

Re:Bad summary

[BJ_Covert_Action]

If the editors themselves don't care about the accuracy of the stories, why should I?

Because you're not kdawson, and that's something to be proud of. ;)

Re:Assumes a CALL to the NULL ptr (not any referen

[McNally]

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.

For further context, see my whitepaper on how to turn any kdawson-posted Slashdot story into a NULL issue.

Not on embedded platforms

[marcansoft]

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.

Re:OS dependent

[hrimhari]

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 .

If you have a bug in kernel code...

[Alex Belits]

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.

Re:Is the kernel address mapping part still true?

[Chris Burke]

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:OS dependent

[Imagix]

But it's a bad summary. They missed the rather critical phrase "how to turn any NULL pointer dereference in the kernel into a root exploit". This isn't about any NULL pointer.

Re:The kernel is at fault.

[0123456]

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