
Deconstruction of Pinkie Pie's 64-bit Chrome exploit - thirsteh
http://scarybeastsecurity.blogspot.se/2013/02/exploiting-64-bit-linux-like-boss.html
======
ck2
My gosh. I wonder how many hours of coding he has under his belt to be able to
come up with something like that. Mind blowing.

Also somewhat terrifying, glad he "works for the good guys".

~~~
clicks
Funny you say that, PinkiePie is (allegedly) 18 years old.

Reminds me of Gennady, (<http://en.wikipedia.org/wiki/Gennady_Korotkevich>)
who keeps getting crazy good scores on TopCoder, Google Code Jam, etc. -- and
he's 18 too.

~~~
lawnchair_larry
I'm not sure how he keeps getting younger. He's in his 20s and in college.

------
gizmo686
For those interested, Pinkie Pie has another chromium hack under his belt [1]

[1] [http://blog.chromium.org/2012/05/tale-of-two-pwnies-
part-1.h...](http://blog.chromium.org/2012/05/tale-of-two-pwnies-part-1.html)

~~~
cerebrum
How much did he get for those exploits? 60k each?

------
adamnemecek
I always wonder how long something like this takes from the start to the end.

------
MatthewPhillips
This is why I read Hacker News. Incredible.

------
ajtaylor
I don't pretend to fully understand everything that's going on with this
exploit, but I give Pinkie Pie full props for being such a genius. Reading
these types of write ups always leaves me with a sense of awe for the hacker.

~~~
zobzu
tbh the exploits themselves are relatively simple when you read them. its like
when I say speaking 7 languages is incredible. When it's what you do all day,
it's also straightforward.

what's generally impressive, is finding them (and thus writing the proper
tools to find them) and having enough dedication to keep at it.

the other impressive thing is the lack of generic fixes even thus we know how
to make them happen (which involve using pretty much using a "written-from-
the-ground-up" OS), apparently, security is fairly low on the "it makes us
lose money, let's fix it all properly" scale ;-)

~~~
daeken
Generally speaking, vulnerability discovery is fairly straightforward, just
requires tenacity and a knack for knowing where to look/fuzz. Exploitation on
this level requires a huge amount of creativity, to know how to fit the
building blocks together into a functioning exploit. Regardless, I'd put them
on about the same level of difficulty, having done both (though I've done far,
far more discovery than exploitation).

> the other impressive thing is the lack of generic fixes even thus we know
> how to make them happen (which involve using pretty much using a "written-
> from-the-ground-up" OS), apparently, security is fairly low on the "it makes
> us lose money, let's fix it all properly" scale ;-)

This is the real meat of this comment, though, and it's what I really want to
respond to. We _don't_ have generic fixes that actually meet our requirements
in terms of performance and developer time. The real, fundamental problem is
simple: memory corruption should not be _possible_ ; put another way, pointers
considered harmful. Possible solutions to this are the
Singularity/RenrakuOS/SharpOS/MOSA approach, where you have a tiny, trusted
compiler that takes on the security risk and generates native code, with the
entire rest of the system running in safe, managed code.

I promoted this concept for a while -- RenrakuOS is mine -- but at the end of
the day, the performance is just not there yet, and won't be for quite a
while. But even more than that, it doesn't solve any of the problems with
logic-related vulnerabilities; these become more and more important as you
eliminate the lower level bugs.

~~~
nikcub
> Exploitation on this level requires a huge amount of creativity, to know how
> to fit the building blocks together into a functioning exploit.

This is what I consider hacking. Not writing another Javascript library.

------
mrmagooey
Does someone have a link to a similar deconstruction of a recent hack
exploiting one of the IE's? It would be interesting to see the relative
complexity of hacks for the two browsers (although I realise that it may also
be an apples-to-oranges comparison)

------
pjmlp
Another example why C and C++ need to be replaced.

~~~
martinced
I upvoted you but yes and no.

Replaced by what? Java? I agree that Java doesn't have buffer
overflows/overrun nor free'ing / spraying issues but have you see how many
critical Java bugs have affected Java lately!? That said the author of TFA
itselfs comments that a rewrite in Java could help...

So I agree that with C / C++ it's always variations of the same old song: it's
either a buffer overflow/overrun or it's some free()'ing / spraying issue and
at one point they start getting old.

Basically what he says is that you either need compiler-based defenses or some
less deterministic heap.

So, once again, randomization is the key here.

It seems that randomization is one of the most important trick against
attackers. In some cases ASLR can already not be defeated anymore (on 64-bit
Linux systems, in some cases). I hope people learn from that and start using
more and more randomization and more heap protection techniques (as apparently
OpenBSD is doing... Of course OpenBSD!).

Now the good thing is that these exploits are starting to get increasingly
difficult to write and people can get paid lots of $$$ to write them legally,
so it seems that there starts to be quite a healthy community of highly
skilled white-hat hackers finding them.

And it's good because any white-hat hacker finding an exploit before a black-
hat means that the exploit gets patched and that it's one less venue for the
bad guys.

As to me I surf inside a VM: a KVM. I'll probably see if I can run a SELinux
inside that KVM.

Because it sure sounds like we're still not anywhere close safe browsing.

~~~
jiggy2011
Well , Java itself is implemented in some lower level language so the JVM can
potentially have heap/stack overflows of it's own.

Java does make it harder for the end user programmer to add these sorts of
vulns to their own code though.

~~~
pjmlp
Not really, unless you are speaking about Oracle's JVM.

~~~
jiggy2011
how so?

~~~
pjmlp
There are many implementations of the Java programming language.

Interpreters, JIT VMs and native code compilers.

Most developers are only familiar with the official VM you can download from
Oracle, which uses a JIT for code execution. This one is a mix of C, C++ and
Java code.

However alone from Oracle (previously Sun) there is a VM implemented in Java
(Maxime), a VM only with C bindings for hardware access with everything else
done Java (Squawk), the C++ code for Hotspot might be replaced with Java
(maybe around Java 9 timeframe, project Graal) and the embedded edition of
Java also supports native compilation.

The Jikes RVM, like Maxime, is a meta-circular VM fully implemented in Java.

Additionally there are native compilers like JET Excelsior.

Despite what people think Java != VM. It is only a question of bootstrapping.

~~~
jiggy2011
Sure, but my point is that any bugs in the low level code (which must be
present somewhere until we have CPUs that can natively understand bytecode)
can bubble up the stack.

~~~
pjmlp
Sure, but that is assuming you produce bytecode at all.

But you're right a program is only safe if the full stack is safe.

------
nextparadigms
Chrome is 64 bit now?

~~~
sathyabhat
Chrome for Linux's been having 64-bit builds for a while now.

------
rorrr
The complexity of this exploit is pretty insane. Just makes me realize how
many people so much smarter than me are out there.

