Deconstruction of Pinkie Pie's 64-bit Chrome exploit | Hacker News Reader

Deconstruction of Pinkie Pie's 64-bit Chrome exploit

scarybeastsecurity.blogspot.se

122 pointsthirsteh33 comments

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

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.

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

He's not 18 years old. He's a college student in his early 20s. Although, he has been pulling off some pretty impressive work since he was a teenager.

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

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

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

This is why I read Hacker News. Incredible.

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.

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 ;-)

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.

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

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

That is very interesting and it's reassuring to know there are still people out there who value security from the ground up, so thanks to you for working on RenrakuOS (didn't know it existed, I like the concept).

" know how to fit the building blocks together " which is, in essence, finding all the vulns at various levels. maybe it's just a difference of point of view after all.

I'm thinking that knowing system architecture, and programming with the various languages used by the program is necessary and natural for exploit research, but maybe that's because I've been around that stuff for too long.

And yes, I was hinting at the kind of OSes you're mentioning. When you're left with logic bugs, it's a huge step forward IMO. Most importantly, as long as you're not having all data in one container the failure of one component does not impact the next component unless you made terrible messaging choices, those being generally extremely controlled to avoid these (which arguably browser vendors are attempting to do right now, but that their browser-based-OSes are trying to decouple)

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)

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

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.

By a strong type language in the lines of Pascal family of languages.

A language with optional bound checking, modules, proper strings and no decay from arrays into pointers. Something along the lines of Ada, Modula-2 or similar.

Additionally micro-kernel architectures with clean separation of process tasks.

I wouldn't have such faith in address space layout randomization. It's an excellent protection, but it makes addresses of code into security-sensitive information; for it to be effective you'll always have to work to prevent leaks of code addresses.

And shameless plug: Rust is designed to be the solution to exactly this sort of thing. The compiler is designed to prove that you can't have pointers into memory that you freed. Obviously, Rust code has to integrate with native libraries, and there can still be bugs there, but it should reduce the attack surface considerably.

Many languages provide memory safety. None of them--none in popular use, anyway--have manual memory management. Granted, most applications that are written in C today don't actually need manual memory management.

Rust provides safe manual memory management.

Fair enough. Can you turn off the gc/explicitly free everything? If not, then e.g. Go provides the same kind of memory management, i.e. controlling the layout of objects in memory.

It would probably be helpful to define what I mean by memory management: controlling allocs and frees. If Rust provides this, great. (Sorry, I don't know Rust very well.) Then your plug is certainly warranted.

Yes, you can write code without ever using the GC. You have to opt-in to use the GC by using the GC'd types, which are not the default. Rust never implicitly promotes anything to the garbage collected heap. There's a compiler lint mode you can turn on that verifies that you don't ever use the GC.

Allocation and freeing can be done manually, using unique pointer types (like std::unique_ptr in C++, except the compiler verifies that it's safe).

Very cool. Thanks.

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.

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

how so?

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.

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.

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.

Chrome is 64 bit now?

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

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

Reply on news.ycombinator.com