
How Google set a trap for Pwn2Own exploit team - dfc
http://www.zdnet.com/blog/security/how-google-set-a-trap-for-pwn2own-exploit-team/10641?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+zdnet%2Fsecurity+%28ZDNet+Zero+Day%29&utm_content=Google+Reader
======
gcp
I don't see the point. Flash is bundled and enabled by default in Chrome. As
long as Google doesn't drop Flash (and they've made it clear they're not going
to do this on desktop), Flash security is very much a Chrome problem.

~~~
trotsky
It matters because including flash with chrome is an act of realism. If the
user runs firefox, safari or another browser they're still going to be
susceptible to the same bug - it simply won't be attributed to the browser
because the user was the one that installed the plugin. By including the
plugin by default they're solving a significantly larger problem than zero
days, namely users that fail to update their plugins on a timely basis (or
plugins that fail to provide a reasonable upgrade path). If the security world
insisted on a technical interpretation (you shipped it so it's your bug) it
would be effectively discouraging a process that is net security positive -
and that's the reason a distinction is made. Note that even VUPEN - whose
business of selling fully weaponized exploits makes them a natural enemy of
better security - tacitly admits the difference by refusing to admit the use
of a flash bug. If they really considered it a non-issue they'd be freely
admitting what they're exploiting. The difference? High security chrome
installations often in use by the kind of targets their government customers
have will frequently have flash disabled or set to click to play.

~~~
ghshephard
Shipping flash is a net security positive? I'd suggest that removing flash
would be a net security positive. Flash will be gone from mobile within a
year, and gone from the desktop within two-three years, so anything the
vendors can do to expedite this process will be appreciated by the community
at large and make us all more secure.

~~~
csulok
removing flash would be better, but right now it's not an option. mobile web
is very very new and it was built without flash, the desktop version is not so
much. not even google can fully and immediately drop flash

------
majmun
Seems like a trap backfired ->
[https://www.google.com/support/forum/p/Chrome/thread?tid=687...](https://www.google.com/support/forum/p/Chrome/thread?tid=687e9c4e6f11e35f&hl=en)

BTW I have to agree if vulnerable flash is included in default installation of
chrome that is essentially the same thing as pwning chrome.

~~~
justinschuh
I wouldn't say it backfired, but after releasing we did discover that some
Flash obfuscators used on games behave almost identically to a JIT spray
attack. This is a shame because their obfuscation technique doesn't really add
any value, but it does hurt performance, consume very large amounts of memory,
and negatively impact stability. We've adjusted the detection to accommodate,
and will make further adjustments as necessary.

~~~
kevingadd
In the future you should consider not adding code like this to your browser,
since it doesn't really add any value either.

~~~
othermaciej
Based on what Justin said, it sounds like what they tried to add is a defense
against JIT spray attacks, not just a detector, which, if effective, would
actually be pretty valuable. JIT spray attacks are pretty dangerous, because
they defeat many of the usual protections against exploiting buffer overflows
for code execution (e.g. DEP and ASLR on Windows). So it certainly would be
valuable to try to defend against these kind of attacks, if that is what the
Chrome folks were doing.

Apparently it was not effective in the end, but we may never know, since VUPEN
doesn't plan to disclose how they escaped the Chrome sandbox.

~~~
justinschuh
Yeah Maciej, that's the gist. The VUPEN guys told us it was effective at
preventing the JIT spray, so they used an information leak to bypass ASLR/DEP.

------
js2
The commit adding the "trap" referred to in the article appears to be:

[http://src.chromium.org/viewvc/chrome?view=rev&revision=...](http://src.chromium.org/viewvc/chrome?view=rev&revision=123205)

The change causes a specific exception when a style of attack known as a JIT
spraying attack is detected. The exception generates a minidump which is
uploaded to Google's crash servers.

Further info:

* <http://code.google.com/p/chromium/issues/detail?id=113891>

* <http://en.wikipedia.org/wiki/JIT_spraying>

------
Maxious
Similar to how some OSX binaries are protected against running on Hackintoshes
with a rather simple plain text key... that when extracted is a poem telling
you not to pirate Mac OS:
<http://www.osxbook.com/book/bonus/chapter7/binaryprotection/>

------
0x0
Anyone got any technical details about this? Judging from the "trap backfired"
link posted elsewhere in the comments, somehow Chrome can ensure the specific
flash crash ends up accessing invalid memory at 0xABAD1DEA... but how?

------
alan_cx
Seems a bit of a risk baiting and humiliating a group of previously white
hatted hackers.

------
cooldeal
I feel a little uneasy about a quickly coded 'trap' being quickly auto-
deployed to tens of millions of machines automatically in a code fix that's
supposed to be about fixing security, only with the intention of making a cute
statement in the cat & mouse game they're playing with the white/grey hats.

The claims of it backfiring in the other comments only make me more uneasy
about all this. I hope they gave a good thought about a 'user first and cute
tricks later' mentality. Don't put 200 million+ users into the crossfire. Or
maybe all this is not a big deal at all.

~~~
chc
You seem to be reading this as "Google knew about an exploit and could have
fixed it, but instead chose to leave a cute message." To me, it sounds more
like Google knew what kinds of exploits people were likely to try and put in
code that would detect some attempts and give a cute error message. The fact
that Vupen later succeeded with a similar exploit basically just proves Google
hasn't solved the halting problem, not that they intentionally left an exploit
in (unless you consider Abobe Flash itself to be an exploit).

------
funkah
I don't get it. This is like leaving your front door open, and then when a
burglar comes in, going "See? I knew you'd do that!"

Then he takes your stuff anyway.

~~~
herdcall
No, this is like putting break-in detectors on front-doors in your community
that you don't control.

~~~
ceol
No, it's like being the mayor of a town but there's this one area you don't
have control over but still had to give the OK to let build and all the
burglars keep getting in through that ar—

On second thought, this is like a software vendor including a knowingly-
insecure program with their product and then discounting exploits because they
used that included program.

