Slashdot Mirror
Pinkie Pie Earns $60K At Pwn2Own With Three Chromium 0-Day Exploits
Tackhead writes "Hot on the hooves of Sergey Glazunov's hack 5-minutes into Pwn2Own, an image of an axe-wielding pink pony was the mark of success for a hacker with the handle of Pinkie Pie. Pinkie Pie subtly tweaked Chromium's sandbox design by chaining together three zero-day vulnerabilities, thereby widening his appeal to $60K in prize money, another shot at a job opportunity at the Googleplex, and instantly making Google's $1M Pwnium contest about 20% cooler. (Let the record show that Slashdot was six years ahead of this particular curve, and that April Fool's Day is less than a month away.)"
OMG!!! Ponies!!!
This space unintentionally left blank.
The best thing about Pwn2Own is that it can be a shot of reality for anyone who gets overly confident in how awesome their favorite OS or browser is. Im a huge fan of Chrome and was hoping it would stand up without any 0-days, but its great that Pwn2Own brought to light the reality that there is no "secure web browsing experience" outside of Lynx (and Im willing to bet that could be 0-day'd too).
I "see" a lot of linux boxes on daily basis (yeah, that was right) and NONE of them has AV, some of the do have some kind of "enterprise protection", but unless you are talking about an email server, on linux you usually do not have any kind of AV running, and yet I (on daily basis again) use chrome and firefox a lot for fun and profit, so, an exploit for them is important for me, AV or not involved.
I'm positive, don't belive me look at my karma
The code isn't in a sandbox if it can escape.
A lot of (desktop) hardware supports virtualization at the hardware level -- This doesn't mean executing a different set of opcodes, it means running an OS inside of an OS. We need hypervisory control at the application level. As long as your application code is running in the same environment as everything else with no hardware supported barriers, then it's not actually in a sandbox.
We compile sections of JavaScript to machine code in data memory, mark the resulting data as code and execute it. It only takes one well placed buffer overflow to get some of your memory corrupted, before data is executed as code. The corruption need not result from JavaScript to affect the JS engine. Additionally, if said JavaScript or HTML or ANY untrusted source of data is being used by native code at the same security level as the application then any bug in that native code (eg: flash, SVG, HTML5 rendering, video/sound codecs, etc) can be an open door out of the "sandbox". This is similar to how such a bug in kernel level code can give you kernel level access... Such is the case for application level code as well.
Data Execution Prevention (DEP) can be used to prevent executing data as code (eg to prevent buffer overflow data from being executed), but since the design of JavaScript makes implementations so slow and we're trying to do so much with it we actually need to execute the data as code. To gain performance we forfeit one of best tools that a "sandbox" can have.
Many that gloat over their browser performance benchmarks wilfully trade security for speed, leaving other more sensible individuals (who may instead throw hardware at a speed issue) without an option... Better browser code can't execute "faster". The hardware runs at the same speed. It can only execute less. That is: more efficiently... More speed requires better hardware, not software.
I would welcome a slower software only VM option (no just in time compiling to machine code), this way hardware DEP could be used to enforce sandboxing more strictly. Until then: My browser runs in its own OS within a hardware supported VM. I start from a fresh known-good VM image before I do anything important on the web. THAT'S a sandbox. Consequently, these restrictions mean I won't do anything important on today's mobile devices...
P.S.
Security researcher red-flags bolded for your convenience.
Its not a meme...we're just celebrating the fact that we live in a universe were we can watch a MLP franchise without being unironic as fuck.
My -1 Troll is actually a +1 funny. And my -1 flame is actually a +1 insightfull.
It's also possible to break out of hardware VMs. Why? Because there's no such thing as a hardware VM. There's hardware-enhanced VMs, but there's still driver and other code which has to interact with the guest OS, thus opening vectors for attack with a much larger attack surface than between two discrete boxes. There have been such exploits published, there are no doubt many unpublished, and there will be more in the future.
Sorry to rain on your parade.
It's not a meme.
You can to accept that virtual security is the same as physical security and cannot be perfect in the real world.
See with physical security, we've known this forever. You can't design the unbeatable system. No matter what you design, someone can figure out a way to overcome it, through brute force if necessary. You can't secure something to perfection. So you don't try, you design security to repel any likely threat you you rely on defense in depth so that if one layer fails, the whole system doesn't fail.
However many geeks seem to have talked themselves in to the idea that you can have perfect virtual security. Just use browser X on OS Y and there is no way anything evil can get you, kind of thing. Well I think that is false. You can't have perfect virtual security. Instead, you just have to make it as good as you can against the threat you are likely to face, and then have defense in depth.
Patch your OS and browser, run an on access virus scanner, run a client firewall, have a network firewall, run as a deprivileged user, use things like ASLR and DEP, be safe about your browsing, monitor your system, etc. Don't rely on a single thing to keep you safe, rely on many. Realize that all your layers have defects. Fix them when found, but understand there is no perfection.
This whining that nobody can build something perfect is just stupid. No, they can't, we never have, never will. Deal with it. We don't move out of our houses because they aren't perfectly secure, we aren't going to stop using our computer because they aren't perfectly secure. Get good layered defense and stay on top of it. That is all you can do, all we've ever been able to do.
The question is whether the flaws are in one of these implementations, in the OS APIs that these depend on, or in the higher-level code that's shared among all platforms. The Windows sandboxing implementation is the most complex (about 20KLoC, while the Capsicum implementation is the simplest at around 100LoC) so it presents the largest attack surface.
I am TheRaven on Soylent News