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.)"
A PARTY!!! (sorry bronies, couldn't resist)
One downside is many are reporting on ZDNet, that the IE 9 exploit that was shown yesterday has new trojans already working for it.
Since it is a 0 day exploit it is undetectable by any anti virus scanner yet and all you need to do is search under Google Image and you are instantly infected without clicking on anything.
Google at least patched the last one in 24 hours, but I do not trust other browsers or users to patch that quick.
http://saveie6.com/
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.