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.)"
A PARTY!!! (sorry bronies, couldn't resist)
It's interesting that the article implies the flaw is in WebKit rather than, say, JavaScript or Flash. So there'll need to be a similar patch made for Safari (which the article also briefly touches on).
#DeleteChrome
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/
Ugh, pwnies.
Life imitates pun.
The Wolfpack Project: BitCoin + Crowdfunding = Political Accountability
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.
As AC above hinted at, and I believe I quote from some famous computer book or another, "If the structural properties of steel changed 20% every ten years, then Civil Engineering as a discipline would look a lot different."
Point being, you can have breakneck advancement or inherently secure code, but not both at the same time.
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
Tell them they must stop this hippocracy.
This might be the first time I've seen a misspelling of "hypocrisy" used as a legitimate pun (hippo=horse, cracy=government). And it isn't even a copypasta (or at least one indexed by Google). Bravo.