5 ms·
Escaping the Safari sandbox with a kernel GPU bug
- billconan 12y agoThank 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?
- linuxfan 12y agoWhat was the title of the book you purchased? Can you share its name?
- billconan 12y agosure, this is the book: http://www.amazon.com/gp/product/1593271441/ref=oh_aui_detailpage_o05_s00?ie=UTF8&psc=1 http://www.amazon.com/gp/product/1593271441/ref=oh_aui_detai... Hacking: The Art of Exploitation, 2nd Edition
- binarycrusader 12y agoThere's also: A Guide to Kernel Exploitation: Attacking the Core http://www.amazon.com/Guide-Kernel-Exploitation-Attacking-Core/dp/1597494860 http://www.amazon.com/Guide-Kernel-Exploitation-Attacking-Co... ...if you're interested in the kernel level exploits. disclaimer: A co-worker of mine co-authored it.
- thoughtpolice 12y agoIf 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.
- ajkjk 12y agoThis 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.
- alkonaut 12y agoThe 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?
- gilgoomesh 12y ago> 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.
- cataflam 12y agoAmazing writeup. An attack from top (javascript) to bottom (kernel bugs), while very clearly explaining the discovery and exploit of vulnerability in each layer. The attack is very impressive, and the writeup makes it seem easy, which is a great compliment on the clarity of the writing. 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.
- brendangregg 12y agoGreat 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-toxic.html 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).
- LeoNatan25 12y agoStill cool, thanks.
- nraynaud 12y agoI 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.
- knweiss 12y ago"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.