Escaping the Safari sandbox with a kernel GPU bug(googleprojectzero.blogspot.com)
googleprojectzero.blogspot.com
Escaping the Safari sandbox with a kernel GPU bug
http://googleprojectzero.blogspot.com/2014/11/pwn4fun-spring-2014-safari-part-ii.html
6 comments
This writeup, and the first part of this series, are amazing and incredibly instructive.
But they make me embarrassed that anyone still runs or writes code that is so without memory safety that these bugs can exist.
The idea of passing around function pointers like raw values that way, or having a language+runtime without array bounds checks or checks for dereferencing invalid pointers is just frightening. We have tools now such that if they had been around in the 60's/70's we wouldn't have these problems. So why not start rebuilding low level systems using better tools? Granted, if we rewrite kernels, drivers, encryption etc in tools preventing stupid low-level bugs, we likely end up creating new high level bugs that were squashed years ago in the old C code. Still, isn't this something that has to be done?
> We have tools now such that if they had been around in the 60's/70's we wouldn't have these problems
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.
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.
Yes we have. Xerox PARC systems were mainly developed in Mesa after some bootstrap work in BCPL.
ETHZ OS were done in Modula-2, Oberon, Active Oberon.
Olivetti and DEC were using Modula-3.
Several OS were being done in Algol and PL/I dialects back when UNIX was being born.
C's ubiquity is a consequence of UNIX adoption by some successful startups in the workstation market.
If one of the other systems had enjoyed a similar adoption another safer systems programming language would have taken C's adoption.
ETHZ OS were done in Modula-2, Oberon, Active Oberon.
Olivetti and DEC were using Modula-3.
Several OS were being done in Algol and PL/I dialects back when UNIX was being born.
C's ubiquity is a consequence of UNIX adoption by some successful startups in the workstation market.
If one of the other systems had enjoyed a similar adoption another safer systems programming language would have taken C's adoption.
If Minix had used something else, then Linus probably/might have used that.
The thing is; Rust could have been implemented long ago. It was triggered by Mozillas need for a parallell browser engine that is safe and doesn't crash all the time. One would have thought the same need would have existed for other code such as kernels and drivers for many years.
Rust looks sexy. And i think Mozilla is using it to implement an alternative render/JS engine or something.
Ada is a modern language that allows for very low level code and is about as fast as C.
Thats what the US military use on mission critical systems, right? Seem to recall reading that it is a pain to work with.
Ada is used in environments were human lifes are at risk life like life support systems, traffic control and so on.
From FOSDEM talks its use has been increasing thanks to C lack of safety, even with MISRA C.
From FOSDEM talks its use has been increasing thanks to C lack of safety, even with MISRA C.
Yeah i guess that having the language enforce the rules makes for safer code than trying to impose safety externally.
Because UNIX was embraced by the enterprise and brought C along.
Algol 68, Modula-2, Mesa, Cedar were all options back when UNIX was being brought to life.
Algol 68, Modula-2, Mesa, Cedar were all options back when UNIX was being brought to life.
That's also a pet peeve of mine: the amalgamation of OS and compiler/language still feels like an odd design (of course, for me who arrived with time machine in the 2000's, so does teletypes and tape archives).
What do you expect? Something (language) at some level needs to have physical access to the physical memory.
(rant ahead) What do I expect? I would expect engineers to identify how awful this situation is years ago and build a replacement. Finally, in the last few years, there are some serious attempts at doing so (Rust comes to mind). But it's taken this long and that astounds me.
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.
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.
Excellent point. I wasn't trying to discount your comment, but your statements here now are clear to me.
As I was implementing a dynamic array (vector) last night in C, I thought about the vector_get method that would implemented. It would first check the bounds that it receives as the second arguments (first is struct vector_t instance), and it would only return if that index is less than the current size of the vector. If the bounds is out of reach, the program aborts.
This was a great example of abstraction in C that I found really enjoyable to write.
As I was implementing a dynamic array (vector) last night in C, I thought about the vector_get method that would implemented. It would first check the bounds that it receives as the second arguments (first is struct vector_t instance), and it would only return if that index is less than the current size of the vector. If the bounds is out of reach, the program aborts.
This was a great example of abstraction in C that I found really enjoyable to write.
Great article! ... I'm glad I already disable hardware acceleration having hit kernel panics there on OS X before. (I did a write up, http://www.brendangregg.com/blog/2014-05-23/osx-10.9.3-is-to..., but it's much less interesting/useful than this blog post).
Still cool, thanks.
"And if you're still running OS X Mavericks or below then why not try it out?"
In other words: "insecure" or "unstable" - choose one.
I'm all for upgrading to Yosemite, but this is a problem.
In other words: "insecure" or "unstable" - choose one.
I'm all for upgrading to Yosemite, but this is a problem.
I always feel a bit strange around security and exploitation people. Security is important, but it's so much easier to destroy and criticize stuff than to build something useful and try to balance all the aspects of a product.
Thank you for sharing, this is a very good reading.
I purchased a book about using buffer overflow to hack stuff. but I'm wondering how those kernel bugs were discovered?
If you want an excellent book on kernel security, I'd suggest buying "A Guide to Kernel Exploitation: Hacking the Core". It's a fairly technical book, so I wouldn't recommend it unless you have exploit and modern operating systems experience, but it's a good book that covers every major platform and a lot of details.
It's probably one of the best technical security related books I've ever read.
It's probably one of the best technical security related books I've ever read.
What was the title of the book you purchased? Can you share its name?
sure, this is the book:
http://www.amazon.com/gp/product/1593271441/ref=oh_aui_detai...
Hacking: The Art of Exploitation, 2nd Edition
Hacking: The Art of Exploitation, 2nd Edition
There's also:
...if you're interested in the kernel level exploits.
disclaimer: A co-worker of mine co-authored it.
A Guide to Kernel Exploitation: Attacking the Core
...if you're interested in the kernel level exploits.
disclaimer: A co-worker of mine co-authored it.
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.