39 ms·

How Google set a trap for Pwn2Own exploit team

97 points by dfc 15y ago

Maxious 15y ago
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/ http://www.osxbook.com/book/bonus/chapter7/binaryprotection/
gcp 15y ago
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.
- sek 15y ago
  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.
  - tvon 15y ago
    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.
    - justinschuh 15y ago
      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.
      - tvon 15y ago
        > 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.
        harshreality 15y ago
        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.
- growt 15y ago
  one more reason to use flash-block. maybe chrome should play flash only after confirmation by default.
  - tjoff 15y ago
    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?
    - daeken 15y ago
      If you enable click-to-play for plugins, it'll prevent it from loading whatsoever before you click it.
      - tjoff 15y ago
        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!
- trotsky 15y ago
  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.
  - gcp 15y ago
    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.
    - cheald 15y ago
      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.
      - cheatercheater 15y ago
        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.
- mistercow 15y ago
  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.
  - gcp 15y ago
    Google has full control over the Flash that is included in Chrome.
    - mistercow 15y ago
      Do you have a citation for that? I have seen no evidence that Google has any access to Adobe's source code.
      - ootachi 15y ago
        Google is rich beyond the dreams of mortal men (quoting patio11). Money can buy access to source code. Not an excuse.
      - gcp 15y ago
        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 :-)
        cpeterso 15y ago
        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.)
- ootachi 15y ago
  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.
majmun 15y ago
Seems like a trap backfired -> https://www.google.com/support/forum/p/Chrome/thread?tid=687e9c4e6f11e35f&hl=en https://www.google.com/support/forum/p/Chrome/thread?tid=687... 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 15y ago
  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.
  - ootachi 15y ago
    If causing crashes isn't backfiring, then I don't know what is.
  - kevingadd 15y ago
    In the future you should consider not adding code like this to your browser, since it doesn't really add any value either.
    - othermaciej 15y ago
      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.
losethos 15y ago
God says... 52:31 And it came to pass in the seven and thirtieth year of the captivity of Jehoiachin king of Judah, in the twelfth month, in the five and twentieth day of the month, that Evilmerodach king of Babylon in the first year of his reign lifted up the head of Jehoiachin king of Judah, and brought him forth out of prison. 52:32 And spake kindly unto him, and set his throne above the throne of the kings that were with him in Babylon, 52:33 And changed his prison garments: and he did continually eat bread before him all the days of his life. 52:34 And for his diet, there was a continual diet given him of the king of Babylon, every day a portion until the day of his death, all the days of his life. ---- God says... in_other_words begs_the_question heathen resume try_again California evolution persistence Sudan God quite how_about_a_comic Indonesia Palestine
0x0 15y ago
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?
funkah 15y ago
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 15y ago
  No, this is like putting break-in detectors on front-doors in your community that you don't control.
  - ceol 15y ago
    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.
cooldeal 15y ago
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.
- ootachi 15y ago
  Google's ego knows no bounds.
- chc 15y ago
  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).
alan_cx 15y ago
Seems a bit of a risk baiting and humiliating a group of previously white hatted hackers.
js2 15y ago
The commit adding the "trap" referred to in the article appears to be: http://src.chromium.org/viewvc/chrome?view=rev&revision=123205 http://src.chromium.org/viewvc/chrome?view=rev&revision=... 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://code.google.com/p/chromium/issues/detail?id=113891 * http://en.wikipedia.org/wiki/JIT_spraying http://en.wikipedia.org/wiki/JIT_spraying

97 points by dfc 15y ago

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/ http://www.osxbook.com/book/bonus/chapter7/binaryprotection/

gcp 15y ago

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.

sek 15y ago
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.
- tvon 15y ago
  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.
  - justinschuh 15y ago
    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.
    - tvon 15y ago
      > 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.
      - harshreality 15y ago
        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.
growt 15y ago
one more reason to use flash-block. maybe chrome should play flash only after confirmation by default.
- tjoff 15y ago
  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?
  - daeken 15y ago
    If you enable click-to-play for plugins, it'll prevent it from loading whatsoever before you click it.
    - tjoff 15y ago
      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!
trotsky 15y ago
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.
- gcp 15y ago
  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.
  - cheald 15y ago
    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.
    - cheatercheater 15y ago
      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.
mistercow 15y ago
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.
- gcp 15y ago
  Google has full control over the Flash that is included in Chrome.
  - mistercow 15y ago
    Do you have a citation for that? I have seen no evidence that Google has any access to Adobe's source code.
    - ootachi 15y ago
      Google is rich beyond the dreams of mortal men (quoting patio11). Money can buy access to source code. Not an excuse.
    - gcp 15y ago
      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 :-)
      - cpeterso 15y ago
        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.)
ootachi 15y ago
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.

majmun 15y ago

Seems like a trap backfired -> https://www.google.com/support/forum/p/Chrome/thread?tid=687e9c4e6f11e35f&hl=en https://www.google.com/support/forum/p/Chrome/thread?tid=687... 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 15y ago
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.
- ootachi 15y ago
  If causing crashes isn't backfiring, then I don't know what is.
- kevingadd 15y ago
  In the future you should consider not adding code like this to your browser, since it doesn't really add any value either.
  - othermaciej 15y ago
    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.

losethos 15y ago

God says... 52:31 And it came to pass in the seven and thirtieth year of the captivity of Jehoiachin king of Judah, in the twelfth month, in the five and twentieth day of the month, that Evilmerodach king of Babylon in the first year of his reign lifted up the head of Jehoiachin king of Judah, and brought him forth out of prison. 52:32 And spake kindly unto him, and set his throne above the throne of the kings that were with him in Babylon, 52:33 And changed his prison garments: and he did continually eat bread before him all the days of his life. 52:34 And for his diet, there was a continual diet given him of the king of Babylon, every day a portion until the day of his death, all the days of his life. ---- God says... in_other_words begs_the_question heathen resume try_again California evolution persistence Sudan God quite how_about_a_comic Indonesia Palestine

0x0 15y ago

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?

funkah 15y ago

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 15y ago
No, this is like putting break-in detectors on front-doors in your community that you don't control.
- ceol 15y ago
  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.

cooldeal 15y ago

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.

ootachi 15y ago
Google's ego knows no bounds.
chc 15y ago
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).

alan_cx 15y ago

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

js2 15y ago

The commit adding the "trap" referred to in the article appears to be: http://src.chromium.org/viewvc/chrome?view=rev&revision=123205 http://src.chromium.org/viewvc/chrome?view=rev&revision=... 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://code.google.com/p/chromium/issues/detail?id=113891 * http://en.wikipedia.org/wiki/JIT_spraying http://en.wikipedia.org/wiki/JIT_spraying