6 ms·

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

102 points by Quekster 14y ago

semenko 14y ago
Direct link to the Chromium blog post: http://blog.chromium.org/2012/10/pwnium-2-results-and-wrap-up_10.html 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=161037 http://src.chromium.org/viewvc/chrome?view=rev&revision=...
- afhof 14y ago
  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.
eranation 14y ago
Can someone please explain the exploit and how it was fixed?
- bvdbijl 14y ago
  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=161037 http://src.chromium.org/viewvc/chrome?view=rev&revision=... The SVG exploit was in Webkit, don't know the exact problem with that
misterS 14y ago
Now there's a bright mind with (possibly) a more-than-good job offer.
- dguido 14y ago
  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.
  - suyash 14y ago
    misterS might be suggesting more job offers for Pinkie Pie
    - dguido 14y ago
      I think he would have left after the first one if he wanted to.
  - WalterGR 14y ago
    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-chrome/ http://www.wired.com/threatlevel/2012/03/zero-days-for-chrom...
    - s_henry_paulson 14y ago
      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.
ChuckMcM 14y ago
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.
tomrod 14y ago
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.
TwoBit 14y ago
Chrome and FireFox patches take hours to be released. IE patches take weeks to be released. Can somebody explain why?
- mkarttic 14y ago
  no. and everyone knows why. Please stop flaming IE, its gotten old.
  - avbor 14y ago
    Honestly, I don't know why. Is it for stability reasons?
    - rrreese 14y ago
      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.
      - avbor 14y ago
        Thanks for the explanation!
  - 14y ago
bookworm_ 14y ago
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.
- evmar 14y ago
  Midori, because it uses WebKit, was surely vulnerable to the same SVG vulnerability and has no sandbox.
  - yeahriight 14y ago
    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.
    - thezilch 14y ago
      Alt+e, s, images, <click> Content Settings, do not show and exception handlers are highlighted.
    - wladimir 14y ago
      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.
    - ajanuary 14y ago
      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.
- 14y ago

102 points by Quekster 14y ago

Direct link to the Chromium blog post: http://blog.chromium.org/2012/10/pwnium-2-results-and-wrap-up_10.html 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=161037 http://src.chromium.org/viewvc/chrome?view=rev&revision=...

afhof 14y ago
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.

eranation 14y ago

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

bvdbijl 14y ago
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=161037 http://src.chromium.org/viewvc/chrome?view=rev&revision=... The SVG exploit was in Webkit, don't know the exact problem with that

misterS 14y ago

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

dguido 14y ago
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.
- suyash 14y ago
  misterS might be suggesting more job offers for Pinkie Pie
  - dguido 14y ago
    I think he would have left after the first one if he wanted to.
- WalterGR 14y ago
  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-chrome/ http://www.wired.com/threatlevel/2012/03/zero-days-for-chrom...
  - s_henry_paulson 14y ago
    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.

ChuckMcM 14y ago

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.

tomrod 14y ago

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.

TwoBit 14y ago

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

mkarttic 14y ago
no. and everyone knows why. Please stop flaming IE, its gotten old.
- avbor 14y ago
  Honestly, I don't know why. Is it for stability reasons?
  - rrreese 14y ago
    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.
    - avbor 14y ago
      Thanks for the explanation!
- 14y ago

bookworm_ 14y ago

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.

evmar 14y ago
Midori, because it uses WebKit, was surely vulnerable to the same SVG vulnerability and has no sandbox.
- yeahriight 14y ago
  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.
  - thezilch 14y ago
    Alt+e, s, images, <click> Content Settings, do not show and exception handlers are highlighted.
  - wladimir 14y ago
    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.
  - ajanuary 14y ago
    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.
14y ago