10 hours later, Google Patches Chrome to Plug Pwnium 2 Security Hole | Hacker News Reader

10 hours later, Google Patches Chrome to Plug Pwnium 2 Security Hole

thenextweb.com

102 pointsQuekster25 comments

Say what you want but I really appreciate the fast turnaround from Google on this. Its excellent that they do this sort of thing, and that they have the mechanism to push the patches quickly.

Direct link to the Chromium blog post: http://blog.chromium.org/2012/10/pwnium-2-results-and-wrap-u...

The commit that closes the exploit: http://src.chromium.org/viewvc/chrome?view=rev&revision=...

Looking at the diff, it doesn't appear anything was really fixed, just removed. I guess that explains the quick turn around time on the exploit.

I tell you, this is one of the biggest selling points to me about products with rapid deployment such as Ubuntu utilities, Firefox, Chrome, and the like. Fixing any bug and pushing an update in hours upon discovery is just awesome. We live in great times.

Chrome and FireFox patches take hours to be released. IE patches take weeks to be released. Can somebody explain why?

Guessing here but I think they have different SLAs. Microsoft probably spends more time testing and releasing something akin to the chrome stable release channel.

no. and everyone knows why. Please stop flaming IE, its gotten old.

Honestly, I don't know why. Is it for stability reasons?

The thing to understand is that Microsoft's main customers are larger business and government, who have large installations. These organisations tend to be very conservative. They don't like to just deploy software/updates, rather they usually put them on test systems and check that the updates don't affect other software.

I.E is also a lot more integrated into windows then the other browsers. So chrome largely just needs to test that their browser works, Microsft needs to test that that the browser works one each version of windows (Vista/7/8) but also all versions (Pro, Home Basic, home Premium etc), but also for all supported languages (Dutch Windows Pro, Dutch Home Basic etc). In addition they need to test that an I.E update doesn't break other software like installers, Office, popular non Microsoft software that makes use of I.E.

Given that their customers will probably take their time updating it makes sense for Microsoft to very carefully test any updates as a hot patch released 10 hours after a bug is found probably won't be widely deployed any faster then one released 10 days later. And 10 hours probably isn't long enough to test all the software that relies on I.E in some manner.

Thanks for the explanation!

Now there's a bright mind with (possibly) a more-than-good job offer.

What makes you think he doesn't already have a job? He's going by a handle because participation in the contest would get him fired from his job.

Yup. To add a citation:

"The tall teen, who asked to be identified only by his handle 'Pinkie Pie' because his employer did not authorize his activity, spent just a week and a half to find the vulnerabilities and craft the exploit, achieving stability only in the last hours of the contest."

http://www.wired.com/threatlevel/2012/03/zero-days-for-chrom...

Translation:

He spends all of his time at work doing stuff like this and doesn't want his employer to find out that he's not actually doing the job he's supposed to.

misterS might be suggesting more job offers for Pinkie Pie

I think he would have left after the first one if he wanted to.

Can someone please explain the exploit and how it was fixed?

It seems there was a bug in some profiling code (that was left behind?). This code made it possible to write arbitrary files on the system, which they fixed by removing the profiling code. This is the commit that fixes that: http://src.chromium.org/viewvc/chrome?view=rev&revision=...

The SVG exploit was in Webkit, don't know the exact problem with that

If I'm going to use Webkit, I'd rather use something simple, like midori. Standard issue on the Raspberry Pi.

Chrome complexity? Browser controlled by commercial entity that sells web ad space? No thanks.

Midori, because it uses WebKit, was surely vulnerable to the same SVG vulnerability and has no sandbox.

Can you disable auto-loading of images in Chrome? If yes, how easy is that to do? It's very easy in midori.

I will always choose simplicity over complexity if I'm concerned about security. Chrome is very complex.

You'll have to verify that disabling auto-loading of images will disable SVG parsing / rendering. SVG is embedded into the DOM tree, and not loaded in an img tag.

Settings, Show Advanced Settings, Content Settings (under Privacy heading), Do not show images (under Images heading). I think that's an extra click to enable Advanced Settings that Midori doesn't have?

Disabling images is a feature. It adds complexity. Yet you're using it as an example of how Midori might allow you to be more secure more easily.

It's the same situation with some of the complex features of Chrome that Midori doesn't have. It's not as simplistic as simple vs. complex, it's a more complicated cost/benefit tradeoff.

Alt+e, s, images, <click> Content Settings, do not show and exception handlers are highlighted.

You mention that Chrome is run by an ad company, but midori lacks decent privacy tools and leaves you much more exposed than Chrome which can run extensions like Adblock Plus and Ghostery. For better or for worse, the web is a complex place and using a simple browser doesn't decrease the complexity outside of your own computer.

Reply on news.ycombinator.com