Dereferencing a NULL pointer always segfaults, right? Not if you're clever... | Hacker News Reader

Dereferencing a NULL pointer always segfaults, right? Not if you're clever...

blog.ksplice.com

65 pointsnelhage16 comments

My first reaction to this headline was "Surely there is never any circumstance where this is genuinely a smart thing to do, no matter how clever" but I confess I wasn't thinking in terms of security vulnerabilities.

Yeah, the last line of the article: "I’ll show you how this lets an attacker use a NULL dereference in the kernel to take over the entire machine."

I believe some old borland compilers mapped 0 to a guard value, and checked if it ever changed to see if there were accidental writes to null.

I feel that was a stupid approach, and having 0 unmapped is actually the better choice -- instant seqfault is imho a better way to know your program failed.

Are you thinking of DOS? I can't imagine a Win32 compiler doing this.

Heh, in DOS a far NULL pointer was the start of the interrupt vector table -- divide by zero being first. I remember writing a program that wrote the address of one of my subroutines to a far NULL pointer and then dividing by zero.

People used to sloppily dereference null pointers on VAX machines because position 0 in memory was always readable and had the value 0.

In a related bit of cleverness I've heard that the JVM doesn't actually put NULL checks in it's generated ASM, instead it installs a SIGSEGV handler that catchs the null pointer exception and does the right thing.

And C# on .NET disallows non-virtual method calls on null instance locations. It does so by emitting a callvirt IL instruction for the non-virtual method, which in turn is translated by the CLR to:

    cmp dword ptr [ecx],ecx

(Assuming 'this' is in ecx.)

I'm not sure who's the intended audience of this. It is called an Introduction to Virtual Memory that is aimed at C programmers.

How many C programmers are out there that do not know how VM works?

Plenty. In fact many get irate when you explain to them that thier nice "close to the metal" language is actualy doesnt talk directly to the memory, it has to go through a (albeit hardware assisted) transform moderated by a couple layers of stuff. The whole point of VM is to keep the illusion of working directly with memory/hw, because it is useful sometimes.

I'll stick around for the second installment, I guess, but this was a bit too basic for my tastes.

Same here. I don't see anything big enough to warrant splitting it into two articles.

Goddamn page views.

There are no ads on that blog. So not sure why pageviews matter, maybe the author just wanted to take a break.

It creates a cool sort of hype actually. I'm not sure if that was intentional.

Check it out: http://lwn.net/Articles/347006/

These null pointers are sometimes function pointers. Wow. You don't even need to muck with the stack and change the return address to get arbitrary code execution.

I admit I'm surprised Linux even lets you mmap 0x0. I suppose most systems won't, since mmap_min_addr will probably be set to a sane address, but it's still a legit vulnerability.

Not under HP-UX on a "PA" processor. The page at 0x0 isn't neccessarily unmapped or marked noread/nowrite/nonothing. As I recall one or the other HP C compilers has a way around this, but unless you take care, you won't use that compiler flag, and you end up having NULL pointer de-refs.

Reply on news.ycombinator.com