Critical Google Chrome hole plugged in 24 hours | Hacker News Reader

Critical Google Chrome hole plugged in 24 hours

arstechnica.com

46 pointsdbh93725 comments

"To date, most successful attacks against Chrome exploit Adobe Flash, which is protected by a significantly more porous sandbox."

I notice that pretty much every time I read articles about Pwn2Own and similar. It's high time that Flash was abandoned as a ubiquitous part of the web. It is to web development as Outlook Express was to desktop software in the 90s - sure it's everywhere, but it's not doing much good by being so.

I keep it disabled in Chrome and selectively enable it for sites I trust or as-needed. I'm glad to see that it's less necessary over time.

A thousand upvotes to you for this information.

If anybody else is looking, this can be done (without addons) under:

[Wrench] > Settings > "Under the Bonnet" Advanced Settings > "Privacy" Content Settings > Scroll down to "Plugins" and select "Click to Play". Manage exceptions as required.

This.

I used to use Flashblock with Chrome but this works just as well, not to mention being built in. I use this setting on my CR-48 (Chromebook).

The Chrome Release blog says it's fixed: http://googlechromereleases.blogspot.com/2012/03/chrome-stab...

And that the SVN commit history is available: http://build.chromium.org/f/chromium/perf/dashboard/ui/chang...

But I don't see any commit that look even remotely related to this exploit. What's up?

The commits are all there, the fixes just might not look completely obvious. We (chromium) commit all fixes to the chromium repository before pushing them to users, always.

Do you guys ever do write-ups about the bugs? I would be interested in reading that.

I don't think we do that as a general habit, but that may happen in this case.

My wild-arsed guess is: http://src.chromium.org/viewvc/chrome/branches/963/src/conte...

-- a change to kUnreachableWebDataURL

Well... They would hopefully be smarter than committing the fix to the public SVN.

By committing the fix, they would effectively be releasing a step-by-step guide on how to exploit the vulnerability.

But it's still an open source project -- perhaps the commits are more evident in their git repo? http://git.chromium.org/gitweb/

Certainly if you build Chromium from git/SVN now, the bug is fixed.

I just find it a little strange that their changelog / list of commits in each version is not true.

If it's a flash problem, I don't think Chromium has flash at all.

As the original article points out, this is not a flash related issue.

With a response time like that it seems like antivirus software is becoming increasingly irrelevant.

With exploits like that, it seems like sandboxing is becoming increasingly irrelevant.

I don't think it's a good argument - what about defense in depth? Don't antivirus packages have heuristic protections? Or are those, in general, useless?

A lot of computer viruses are spread by confused or ignorant people. It's not all about security holes....

Meanwhile, critical Android security holes remain unpatched for more than 2 yrs.

A real security hole, or one like "if someone watches you type your PIN code, they'll know your PIN code"?

Security holes that render the permissions system completely useless, since even a no-permissions app can end up doing anything.

Do you have an example?

The cases I've read about were of the form "app A asks app B to do something it can't via the Intent system". That sounds scary until you realize that a standard example of this is an app that can't access the network sharing something via email. In other words, app A has transferred control to app B and what the user does (or doesn't) decide to do with app B is their choice, not app A's.

Indeed. Delegation via intents makes things more secure as broken code can be patched in one place rather than in many. And, you get tighter control over what apps can do: if you never want an app to share something via Facebook, simply uninstall the app that provides the "share via Facebook" intent.

Interesting point. Sometimes I find myself wanting to keep the app, but drop the intent. Usually that is to shorten a list, but not always. I'd love to see low-level intent-blocking (as well as low-level, fine-grained permissions blocking, but that's a whole other story).

That's only the Pwnium hack, though. The Pwn2Own vulnerability remains undisclosed and unfixed.

Which leads me to the question: why aren't companies like Google customers of companies like Vupen? Too many of them to make it cost-effective? Or does Vupen (for example) prefer if those holes are not fixed? You can sell a vulnerability many times, after all.

Vupen sells 0day exploits so that they can be used to attack people: http://www.vupen.com/english/services/lea-index.php

A patched vulnerability would not be worth nearly as much to them and their customers.

P.S. Vupen sells to ASEAN. ASEAN includes Burma (Myanmar). Burma is not a happy place.

How hard would it be for Google to be a customer of Vupen without representing themselves as Google?

Reply on news.ycombinator.com