Is that the case? My understanding was that they were offering an additional bounty however the rules to claim that was a bit more strict than the standard pwn2own rules. I could be mistaken though...
Not sure if the rules were stricter, but Chrome's increased bounty from Google was the main thing I wanted to hear about in this contest. It's a nice PR move if Chrome isn't hacked successfully, and probably a nice recruitment move if it is.
Chrome has superior sandboxing of the rendering engine than Safari, so even if you could crash Chrome with the bug, actually doing something "useful" would be significantly more difficult.
Theoretically that may be, but this time Chrome won only because the contestant didn't show up.
"The third browser to be tested was scheduled to be Chrome. However, the contestant registered to attempt the attack did not show up, so the browser remains unbeaten."
I wonder if there is a reason he didn't show up. For example, perhaps he was incapable of demonstrating any exploit. It's not as simple as "it would have been compromised if the contestant showed up."
> This is because, in a change to historic competition rules, the system configuration was frozen last week, so the last-minute fix hasn't prevented exploitation.
then later
> One possible reason for this is that Google published a Chrome update yesterday, closing at least 24 security flaws. The would-be Chrome attacker may have been depending on one of these flaws to attack the browser.
I thought the configuration was frozen last week. Was that only for Apple? On first read, this seems like a faulty conclusion based on the earlier statement.
You're right about the inconsistency, it seems an older version of chrome would be the target. I think this rule was unannounced though, or maybe even made up in the last 24 hours as google and apple pushed updates. So understandable I think, or at least I made the same mistake :/
...Address Space Layout Randomization (ASLR) are well-known
Note that unless things have changed (something which I can find no evidence for,) snow leopard still lags behind windows and linux in its ASLR, in that it doesnt randomise all the key parts of the kernel. Hopefully this will be fixed in lion.
it is sad to see apple mac/osx fail now for the 5th year in pwn2own; that means apple doesnt take their task seriously,as much as they take ux polishing and leak-hyping. that explains why on mac os/x safari usage lags behind others; given a competitive environment apple products can't compete.
24 comments
[ 3.0 ms ] story [ 63.2 ms ] thread"The third browser to be tested was scheduled to be Chrome. However, the contestant registered to attempt the attack did not show up, so the browser remains unbeaten."
then later
> One possible reason for this is that Google published a Chrome update yesterday, closing at least 24 security flaws. The would-be Chrome attacker may have been depending on one of these flaws to attack the browser.
I thought the configuration was frozen last week. Was that only for Apple? On first read, this seems like a faulty conclusion based on the earlier statement.
Which means even though Apple patched the 60 vulnerabilities the researcher used a one that was not known and thus not patched.
Note that unless things have changed (something which I can find no evidence for,) snow leopard still lags behind windows and linux in its ASLR, in that it doesnt randomise all the key parts of the kernel. Hopefully this will be fixed in lion.
http://www.theregister.co.uk/2009/08/29/snow_leopard_securit...
https://secure.wikimedia.org/wikipedia/en/wiki/Address_space...
EDIT: although apparently, as ever, the community comes to the rescue. Stefan Esser presents steps to randomise dyld's address space yourself: http://antid0te.com/antid0te-for-snow-leopard-rebasing-dyld....