Of course, and as mentioned at the end, the actual discovery process was much messier :)
As a bonus, there are a lot of links to other interesting documents as well.
Not for kernel development we don't.
The only modern, memory-safe language that gets close(-ish) to the performance of C for kernel development is Rust and it's a long way from being stable enough for mainstream kernel development.
And even a safe language like Rust won't prevent escalation problems like this if you're placing too much trust in incoming data. That's a design problem that has nothing to do with languages or memory safety.
Algol 68, Modula-2, Mesa, Cedar were all options back when UNIX was being brought to life.
You'll get no argument from me that a language needs direct access to memory. My problem is that the difference between correct code and exploitable code is extreme diligence on the part of the programmer, which fails constantly. [Arguably static analysis type tools can help a lot, but, that's just trying to recover from an already bad situation.]
For example, in the prequel to the OP's article (http://googleprojectzero.blogspot.com/2014/07/pwn4fun-spring...), the original bug was overflowing an unsigned int. You should be spitting out your coffee! (/beverage of choice) How can it be be that a (presumably expert) programmer can write code that silently overflows integers by accident?
"It's 2014 and this still happens." That's my favorite non-argument. It's not constructive but it expresses how I feel. We're well past the years where people have had time to reflect on the fact that people have already struggled with and tried to solve the problem that this should simply not be possible. I don't need a fancy type system to enforce 'checked integers' are the only things that are passed to to my memcpys - but I do have to be willing, at some point, to discard the broken versions of the same thing I've been holding on to for 30 years in favor of something less perilous.
Oh, and, if you read the rest of that prequel article, the person who fixed the bug missed something else in doing so. They're adding overflow-safe versions of 'size_t' and 'unsigned int' together. Again, embarrassing. Not for their error, but because we-as-a-species are still writing code where that mistake can be made, and then not doing anything about it when it inevitably happens.
In other words: "insecure" or "unstable" - choose one.
I'm all for upgrading to Yosemite, but this is a problem.
It's probably one of the best technical security related books I've ever read.
Hacking: The Art of Exploitation, 2nd Edition
