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.
Really...and here we thought SElinux was supposed to be 'more secure'. I love linux, and could read through the kernel source all day long, its freakin' beautiful, and have utmost respect for its developers. But I can't help but laughing when someone finds a vulnerability in the code, because...well you know how those kernel guys are...:-)
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.
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...
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.
16 comments
[ 0.28 ms ] story [ 43.4 ms ] threadNow why I haven't seen anybody screaming "WTF is a setuid program loading and running arbitrary code for?" is still a mystery.
Otherwise we'll be playing null pointer dereference cat&mouse for ever.
The real WTF here is that people are still building "secure" software in a language where programmer mistakes cause undefined behavior...