

A new fascinating Linux kernel vulnerability - timf
http://isc.sans.org/diary.html?storyid=6820

======
modeless
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.

~~~
tedunangst
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.

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

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

~~~
LogicHoleFlaw
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.

~~~
jacquesm
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.

~~~
tptacek
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.

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

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

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

~~~
modeless
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...

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

~~~
modeless
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.

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

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

