How Google set a trap for Pwn2Own exploit team

Re:How Google set a trap for Pwn2Own exploit team by trotsky on Saturday March 10, 2012 @11:04AM (#3687981)

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.

[ Parent | on HN ]

Re:How Google set a trap for Pwn2Own exploit team by ghshephard on Saturday March 10, 2012 @02:50PM (#3688538)

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.

[ Parent | on HN ]

Re:How Google set a trap for Pwn2Own exploit team by csulok on Sunday March 11, 2012 @07:46AM (#3690198)

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

[ Parent | on HN ]

Re:How Google set a trap for Pwn2Own exploit team by gcp on Saturday March 10, 2012 @12:25PM (#3688171)

It's been made clear that not bundling Flash is a sustainable act, if you have the guts to do it. Apple had. Google doesn't. If Google took a firmer stance there, Flash would be dead faster.

[ Parent | on HN ]

Re:How Google set a trap for Pwn2Own exploit team by cheald on Saturday March 10, 2012 @02:15PM (#3688457)

I think it's utterly ridiculous to take the stance that Flash is moving towards dead on desktop devices. Flash is effectively dead on mobile, and that primarily for battery reasons. Flash is still very much a big part of the desktop web, and will be for the foreseeable future.

[ Parent | on HN ]

Re:How Google set a trap for Pwn2Own exploit team by antihero on Saturday March 10, 2012 @08:40PM (#3689304)

And it definitely should not be until they sort their security and stop pissing around with Linux. Flash is proprietary, crashy, bullshit that can't die sooner. The only advantage it has for video is pretty neat streaming support that could most likely be solved in other ways, and being able to place adverts over the damn video.

[ Parent | on HN ]

Re:How Google set a trap for Pwn2Own exploit team by cheald on Saturday March 10, 2012 @09:53PM (#3689402)

Nobody will deny that it's full of security holes, a resource hog, and woefully undersupported on Linux. But I also think it's pissing into the wind to claim that we have equivalent solutions and it's just a matter of waiting for Flash to die now.

We're making progress in that direction, but it's going to be years before there's a significant dent made.

[ Parent | on HN ]

Re:How Google set a trap for Pwn2Own exploit team by Skrekkpus on Wednesday March 14, 2012 @05:09AM (#3702360)

Although it is true there are security problems, it is silly to think that is something unique for flash. WebGl is probably the most insecure plugin right now, largely because there is no one company responsible for upgrading it. Although there are problems with flash, Adobe seem to have high priority on patching it. canvas/webGl/SVG can't deliver yet.

[ Parent | on HN ]

Re:How Google set a trap for Pwn2Own exploit team by eftpotrm on Saturday March 10, 2012 @03:36PM (#3688658)

What for, though? I'm another Flashblock user and it seems to lose me ads and videos. The ads don't benefit me anyway, the videos are now capable of being deployed by other means; it's just the vendors haven't yet caught up.

Flash is on life support, and I don't see a way back for it.

[ Parent | on HN ]

Re:How Google set a trap for Pwn2Own exploit team by cheald on Saturday March 10, 2012 @05:18PM (#3688867)

Audio is a big one. The HTML5 audio APIs just haven't caught up yet. Live video, as mentioned elsewhere, is big as well. The vast majority of web games are still Flash, as well. Even video delivery is more robust with flash than with HTML5 - ever tried doing a preroll on an HTML5 <video> tag? Notice that it basically...doesn't work?

Flash is certainly has less of a monopoly on "interactive web content" than it once did, but it still fills an extremely important and currently unreplacable role on the web. To be ringing its death toll just yet is premature.

[ Parent | on HN ]

Re:How Google set a trap for Pwn2Own exploit team by wahnfrieden on Saturday March 10, 2012 @06:09PM (#3688998)

Indeed, the audio tag is basically entirely broken and unusable in a general sense... Most comical is android supporting the tag but not any audio decoding codecs.

[ Parent | on HN ]

Re:How Google set a trap for Pwn2Own exploit team by gduffy on Saturday March 10, 2012 @05:03PM (#3688838)

Live streaming. Especially low (well, lower than HLS for example) latency streaming.

[ Parent | on HN ]

Re:How Google set a trap for Pwn2Own exploit team by cheatercheater on Saturday March 10, 2012 @02:26PM (#3688488)

i have flashblock on. the only time i notice it's on is when... oh wait, I don't notice it being on at all anymore. For me, flash does not exist.

[ Parent | on HN ]

Re:How Google set a trap for Pwn2Own exploit team by ja27 on Sunday March 11, 2012 @06:01PM (#3691417)

Flashblock still loads the plugin and content, doesn't it? I don't run Flashblock, but does this still work: http://hackademix.net/2008/06/08/block-rick/

I disable plugins in Chrome and either whitelist sites or run them as-needed.

[ Parent | on HN ]

Re:How Google set a trap for Pwn2Own exploit team by ootachi on Saturday March 10, 2012 @01:05PM (#3688265)

Google could run Flash in a VM. Or they could re-implement it (as Mozilla is doing). Or they could buy it from Adobe (they're Google). Or they could pay Adobe to write a version that uses the sandbox. Or they could just stop shipping it.

They aren't fooling anyone. It's Google's problem.

[ Parent | on HN ]

Re:How Google set a trap for Pwn2Own exploit team by trotsky on Saturday March 10, 2012 @01:41PM (#3688352)

Google could run Flash in a VM. Or they could re-implement it (as Mozilla is doing). [...] Or they could pay Adobe to write a version that uses the sandbox.

Isn't the nacl+pepper flash rewrite effectively the result of doing a bit of all three?

[ Parent | on HN ]

Re:How Google set a trap for Pwn2Own exploit team by jaredsohn on Sunday March 11, 2012 @05:10AM (#3690012)

> Or they could re-implement it (as Mozilla is doing)

Link? I haven't heard anything about this.

[ Parent | on HN ]

Re:How Google set a trap for Pwn2Own exploit team by ootachi on Saturday March 10, 2012 @01:02PM (#3688255)

Exactly. Saying "that wasn't a real exploit!", as the Chrome security team often does, is counterproductive at best and childish at worst. Security exists to protect users, not to boost Google's ego. When there is a hole, it doesn't matter where it is: it's a flaw in Chrome, it's Google's responsibility as the vendor of Chrome, and it needs to be fixed.

[ Parent | on HN ]

Re:How Google set a trap for Pwn2Own exploit team by mistercow on Saturday March 10, 2012 @11:20AM (#3688024)

The point of the contest, from Google's perspective, is to discover vulnerabilities so that they can patch them. Allowing teams to find vulnerabilities in code Google doesn't control does not serve that purpose.

[ Parent | on HN ]

Re:How Google set a trap for Pwn2Own exploit team by gcp on Saturday March 10, 2012 @12:24PM (#3688166)

Google has full control over the Flash that is included in Chrome.

[ Parent | on HN ]

Re:How Google set a trap for Pwn2Own exploit team by mistercow on Saturday March 10, 2012 @12:54PM (#3688231)

Do you have a citation for that? I have seen no evidence that Google has any access to Adobe's source code.

[ Parent | on HN ]

Re:How Google set a trap for Pwn2Own exploit team by gcp on Saturday March 10, 2012 @01:07PM (#3688275)

I don't think this has been publicly admitted. I'm fairly certain for 3 reasons though:

1) Google contributes tons of security fixes to Flash. 2) Google announced they will rework Linux Flash to use PPAPI and make it Chrome only. Adobe seems to have abandoned Linux Flash entirely. Logical conclusion is what Google will do this themselves - and they'll need the source code for that. 3) Android shipped with Flash and Google pushed it as a major feature over iOS. This also points to strong collaboration. Android had Flash very early - much earlier than Adobe could have done it themselves.

I admit I was also trolling here to see if one of the Google security guys (who already posted in other threads regarding this) would bite and deny it - in which case I have an indication to the contrary :-)

[ Parent | on HN ]

Re:How Google set a trap for Pwn2Own exploit team by cpeterso on Saturday March 10, 2012 @02:29PM (#3688494)

I was an engineer on Adobe's Flash team.

Google's Chrome team has full access to Adobe's Flash code. The Chrome team maintains their own Flash builds and releases. That's how they can do things like Pepper, even if Adobe doesn't care about Pepper for other platforms. There have been news stories about Chrome updating their Flash a day or two before Adobe, thus revealing security holes in other browsers' Flash.

Google's Android team, for mysterious lawyery reasons, does not access to any Flash code. Adobe had an army of 10-20 engineers and QA working exclusively on Flash for Android. (This is yet another example that Android's device fragmentation is an expensive problem and requires lots of manpower.)

[ Parent | on HN ]

Re:How Google set a trap for Pwn2Own exploit team by georgemcbay on Saturday March 10, 2012 @03:38PM (#3688661)

The source code for Flash is not exactly a closely guarded secret, there are quite a few companies that have licenses to it. I'd be shocked if Google wasn't one of them.

[ Parent | on HN ]

Re:How Google set a trap for Pwn2Own exploit team by ootachi on Saturday March 10, 2012 @01:07PM (#3688273)

Google is rich beyond the dreams of mortal men (quoting patio11). Money can buy access to source code. Not an excuse.

[ Parent | on HN ]

Re:How Google set a trap for Pwn2Own exploit team by growt on Saturday March 10, 2012 @10:02AM (#3687869)

one more reason to use flash-block. maybe chrome should play flash only after confirmation by default.

[ Parent | on HN ]

Re:How Google set a trap for Pwn2Own exploit team by tjoff on Saturday March 10, 2012 @07:25PM (#3689171)

I haven't seen a flash-block implementation in chrome that hinders execution of flash. Often the flash is able to load before it is blocked which kind of defeats the purpose (from a security standpoint). Or have I missed something?

[ Parent | on HN ]

Re:How Google set a trap for Pwn2Own exploit team by daeken on Saturday March 10, 2012 @08:28PM (#3689278)

If you enable click-to-play for plugins, it'll prevent it from loading whatsoever before you click it.

[ Parent | on HN ]

Re:How Google set a trap for Pwn2Own exploit team by tjoff on Sunday March 11, 2012 @02:17PM (#3690862)

Can't believe I didn't know about that. But I can't find it? (all I can find is that is supposed to be in about:flags) Is it available in stable chrome releases?

Edit: Never find what I'm looking for in chrome settings... It's in Options -> Under the hood -> Content settings... (or just chrome://settings/content ) and then you can enable click-to-play under plugins.

Thanks!

[ Parent | on HN ]

Re:How Google set a trap for Pwn2Own exploit team by sek on Saturday March 10, 2012 @09:09AM (#3687792)

It is not their program, they can't do much about it and everyone else has also Flash installed. In reality this vulnerability is present on 99% of all devices and not just chrome. Compare Flash having a sandbox, to all the other browsers who don't have one. In the end, Chrome is by far the most secure browser.

[ Parent | on HN ]

Re:How Google set a trap for Pwn2Own exploit team by tvon on Saturday March 10, 2012 @10:46AM (#3687938)

They can very easily stop including the Flash player with every version of Chrome. It seems like that would solve some obvious security problems.

This is hardly an impossible feat.

[ Parent | on HN ]

Re:How Google set a trap for Pwn2Own exploit team by justinschuh on Saturday March 10, 2012 @11:23AM (#3688027)

The problem is that an outdated, unsandboxed version of Flash is installed on almost every desktop system. So, if we stopped including Flash, the vast majority of our users would be more vulnerable than they already are. That's why we're shipping a current version with a sandbox that's at least as good as IE low integrity mode, and we're also wrapping up work on a version of Flash that uses the full Chrome sandbox.

[ Parent | on HN ]

Re:How Google set a trap for Pwn2Own exploit team by tvon on Saturday March 10, 2012 @11:54AM (#3688090)

> The problem is that an outdated, unsandboxed version of Flash is installed on almost every desktop system.

Don't use it.

> So, if we stopped including Flash, the vast majority of our users would be more vulnerable than they already are.

Prompt to use a specific Flash when the user requests it.

[ Parent | on HN ]

Re:How Google set a trap for Pwn2Own exploit team by harshreality on Saturday March 10, 2012 @11:51PM (#3689584)

If Chrome didn't bundle a better version of flash, and didn't use the system version of flash, users would find out that Chrome is "broken" the first time they got to a page with flash. Then they would switch to Firefox, Opera, or even IE if they're on windows. Those browsers do use the system flash plugins. Who wins? Not security.

If Chrome didn't bundle a modified version, and prompted the user to select a Flash version, the only one they could offer would be the system one.

Unless you're saying that the Chrome team should go to all the effort to build a custom version of flash, but only deliver it to Chrome browsers when the user specifically requests it? That strategy seems DOA from a cost/benefit analysis perspective.

[ Parent | on HN ]