5 ms·

A new fascinating Linux kernel vulnerability

36 points by timf 17y ago

modeless 17y ago
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.
- jpierce420 17y ago
  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...:-)
- tedunangst 17y ago
  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.
yread 17y ago
Hah I guess you can get the habit of first dereferencing and then testing for null only when writing kernel code!
tptacek 17y ago
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 17y ago
  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 17y ago
    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 17y ago
      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 17y ago
        That's true. That would defeat such a check because the 0th location would never be hit.
prodigal_erik 17y ago
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 17y ago
  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 17y ago
    So why isn't gcc throwing big warnings and errors about dead code paths?
    - modeless 17y ago
      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 17y ago
So what us the reason that mapping om 0 is allowed anyways ?
cbr 17y ago
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.
known 17y ago
Why don't we hear such exceptional bugs in Windows kernel?

36 points by timf 17y ago

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.

jpierce420 17y ago
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...:-)
tedunangst 17y ago
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.

yread 17y ago

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

tptacek 17y ago

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 17y ago
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 17y ago
  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 17y ago
    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 17y ago
      That's true. That would defeat such a check because the 0th location would never be hit.

prodigal_erik 17y ago

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 17y ago
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 17y ago
  So why isn't gcc throwing big warnings and errors about dead code paths?
  - modeless 17y ago
    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 17y ago

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

cbr 17y ago

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.

known 17y ago

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