

Escaping the Safari sandbox with a kernel GPU bug - silenteh
http://googleprojectzero.blogspot.com/2014/11/pwn4fun-spring-2014-safari-part-ii.html

======
cataflam
Amazing 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.

------
ajkjk
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.

~~~
alkonaut
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?

~~~
gilgoomesh
> 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.

~~~
pjmlp
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.

~~~
illumen
If Minix had used something else, then Linus probably/might have used that.

------
brendangregg
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...](http://www.brendangregg.com/blog/2014-05-23/osx-10.9.3-is-toxic.html),
but it's much less interesting/useful than this blog post).

~~~
LeoNatan25
Still cool, thanks.

------
knweiss
"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.

------
nraynaud
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.

------
billconan
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?

~~~
thoughtpolice
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.

~~~
linuxfan
Thanks much for info on this book

