A new fascinating Linux kernel vulnerability | Hacker News Reader

A new fascinating Linux kernel vulnerability

isc.sans.org

36 pointstimf15 comments

Everyone is focused on this removal of the null check by the compiler, but to me that's a red herring. The real bug is the fact that SELinux allows you to map memory to address 0! Fix that and this is much less serious.

Apparently that's a deliberate design decision to allow root to map 0, which is why the attack vector goes through pulseaudio.

Now why I haven't seen anybody screaming "WTF is a setuid program loading and running arbitrary code for?" is still a mystery.

I'm confused by the assertion that a source code audit would catch nothing. Even if the auditors didn't know that the check would be optimised away, the code is very unnatural. Normally you check if a pointer is NULL and then deference it. In a code review, every time I see a pointer dereference I'm thinking: "how do we know that's not NULL?". So a check afterwards should not keep this code from being caught by auditors.

It's worth noting that this is a pathological NULL deference case, but that over the last couple years researchers have begun to make an art out of finding straightforwardly-exploitable NULL dereferences, particularly in the kernel; on some platforms, +0h is natively dereferenceable, and some dereferences are done with near-arbitrary offsets.

If I recall, AIX is one system which always returns 0 if NULL is dereferenced - the word at address 0 is guaranteed to a) be addressable, and b) contain a 0. These days I guess it's a security vulnerability, but the original intention was to allow wizards to optimize away the need for certain null checks. IBM actually has a number of patents related to techniques such as array boundary checking under this system.

I'm all for making the 0 page non-existent and to make it a processor feature rather than an os feature that the 0th address being referenced in any way will generate a hardware exception no matter what.

Otherwise we'll be playing null pointer dereference cat&mouse for ever.

It doesn't matter what you do with the zero page if the address is getting offset with an attacker-controlled caddr_t. I'm skeptical about NULL pointer countermeasures.

That's true. That would defeat such a check because the 0th location would never be hit.

Hah I guess you can get the habit of first dereferencing and then testing for null only when writing kernel code!

Wow, gcc generates code that's incorrect unless memory protection is being enforced? I didn't even realize it would be possible to build a kernel that way.

GCC's code isn't incorrect. As per the C standard, after you've dereferenced a NULL pointer then all behavior is undefined. If GCC emitted code that launched ICBMs after a NULL pointer dereference, that wouldn't violate the spec either.

The real WTF here is that people are still building "secure" software in a language where programmer mistakes cause undefined behavior...

So why isn't gcc throwing big warnings and errors about dead code paths?

My guess is that GCC's dead code warning is produced in a pass that runs before the optimizer and isn't smart enough to prove the code is dead.

So what us the reason that mapping om 0 is allowed anyways ?

Why don't we hear such exceptional bugs in Windows kernel?

Reply on news.ycombinator.com