

Detailed explanation of a recent privilege escalation bug in Linux - wheels
http://timetobleed.com/detailed-explanation-of-a-recent-privilege-escalation-bug-in-linux-cve-2010-3301/

======
Robin_Message
That's a very nice write up of that kernel exploit. One question — it says at
the end that "subtle bugs like this are very difficult to catch via code
review." Shouldn't the checking of eax when the very next function uses rax to
index a table have been a red flag? Obviously there is more to the exploit so
it still wouldn't be obvious, but shouldn't that have been enough?

~~~
tptacek
It's a red flag _now_ , but prior the vulnerability being discovered, it was
just one of 46348763487653 possible red flags people could have thought of.

In C, this would be a short/long truncation error, and the compiler would
catch it --- except in situations like this, where the variable in question
was being used in two different functions. So the idea that it could have been
easy to catch in assembly is hard to embrace.

~~~
Robin_Message
My point was only that if you walked through the functions as they are used
(as I would expect a code review to do) the eax/rax difference ought to be
sufficient to investigate further. Even if you don't see the exploit, you
could still fix the length mismatch.

The mechanism for calling into the kernel is not some half-arsed, barely
important piece of code; it's one of the few surfaces the kernel should
actually need to defend. A line-by-line walk-through is a lot of effort, but
surely not too much on a small amount of extremely important and potentially
exploitable code.

Am I expecting too much from Linux or from code reviews in general?

~~~
tptacek
Here's what I'm saying:

* Before this issue was found, it was not reasonable to expect people to find rax/eax truncation in routine audits.

* Now that it's been found, it is reasonable (though not automatic) to expect a codebase-wide rXx/eXx truncation bug hunt, _a la_ OpenBSD in the '90s.

* Now repeat this cycle 85789789343 times as people find new random nits that blow up the Linux security model, and you see the challenge.

~~~
Robin_Message
Thanks for the clarification. Given the way this cycle is bound to repeat, do
you see any mileage in attempts to use typed assembly languages or other
static analysis tools on things like the kernel? I've never seen them as
worthwhile for application software, but they could definitely prevent this
kind of bug, and if current techniques aren't stopping these bugs, then would
it be worth the investment?

