4 ms·

Is it up to the contestant to release the vulnerability or not? I must admit that I haven't read the rules so thoroughly, but could a contestant potentially win

by hucker 16y ago

Is it up to the contestant to release the vulnerability or not? I must admit that I haven't read the rules so thoroughly, but could a contestant potentially win and never disclose the vulnerability even to the vendor? If so I agree with the article to some extent. I do however think that there is some value with this event as it is one of very few such events to be covered by main stream media for some reason (at least here in Norway), and it puts the fact that browsers aren't always safe in the spotlight even for the general population.

darren_ 16y ago
Pretty sure TippingPoint ZDI gets the details of your vulnerability as part of the contest, and they notify vendors and either a) release publicy if there's no real response from the vendor or b) give them a 'reasonable timeframe' to workin to fix the vulnerability.
tptacek 16y ago
They essentially sell the vulnerability at CanSec. In other words, if you find a vulnerability in November, and it's a good one, you might as well not tell anybody about it and take your shot at winning $15,000 and a press hit. Speaking as a practitioner: we do not want for vehicles for media coverage. CanSec does not improve public understanding of vulnerability research. If anything, as Zalewski points out, it degrades it.
- kenjackson 16y ago
  Correct. Although the attacks at pwn2own are full exploits, not just vulnerabilities. For example, the attack against IE8 was three vulnerabilities. And each one in isolation I suspect was at least "Important", but it is possible that each in isolation may not have been "Critical". But by seeing them chained together in an actual exploit you (a) see that these vulnerabilities need to be fixed and (b) may find a new exploit technique that may not have been known by the vendors if a white hat hadn't gone through the effort to actually "weaponize". And this is one of the big differences between white and black hats, which I'm sure you're aware of. White hats often find and patch vulnerabilities, but rarely develop full exploits. Black hats are all about full exploits. While intricately related, aren't equivalent.
  - tptacek 16y ago
    There is no browser vendor right now that isn't taking memory corruption vulnerabilities seriously. It isn't '99 anymore. We're not battling it out in the papers about "theoretical" vulnerabilities. When people report "possible code execution" without exploits, Microsoft sticks "possible code execution" in the MSRC alert. Somebody out there who has had a bad experience with MSFT is going to shellack me for saying that, but "getting vendors to take bugs seriously" is a really, really flimsy argument for a program that bribes researchers to bottle up their findings.
    - kenjackson 16y ago
      There are vulns that aren't fixed that by themselves don't seem so bad, but in conjunction with others are. And there are examples that aren't fixed today. For example, there's a disclosure of information bug in IE8 that exists, but you need the location of the target file to exploit it. If there's another exploit that lets you drop files outside the sandbox, and another exploit where you can overflow a buffer outside the sandbox on reading a file, you now have three vulns that together get you to run code, but any two of them is not sufficient. Note, I based this on SA38416, despite the fact that it appears possible/likely that this vulnerability actually doesn't exist as stated, but it was fine for expository purposes.

by hucker 16y ago

darren_ 16y ago

Pretty sure TippingPoint ZDI gets the details of your vulnerability as part of the contest, and they notify vendors and either a) release publicy if there's no real response from the vendor or b) give them a 'reasonable timeframe' to workin to fix the vulnerability.

tptacek 16y ago

They essentially sell the vulnerability at CanSec. In other words, if you find a vulnerability in November, and it's a good one, you might as well not tell anybody about it and take your shot at winning $15,000 and a press hit. Speaking as a practitioner: we do not want for vehicles for media coverage. CanSec does not improve public understanding of vulnerability research. If anything, as Zalewski points out, it degrades it.

kenjackson 16y ago
Correct. Although the attacks at pwn2own are full exploits, not just vulnerabilities. For example, the attack against IE8 was three vulnerabilities. And each one in isolation I suspect was at least "Important", but it is possible that each in isolation may not have been "Critical". But by seeing them chained together in an actual exploit you (a) see that these vulnerabilities need to be fixed and (b) may find a new exploit technique that may not have been known by the vendors if a white hat hadn't gone through the effort to actually "weaponize". And this is one of the big differences between white and black hats, which I'm sure you're aware of. White hats often find and patch vulnerabilities, but rarely develop full exploits. Black hats are all about full exploits. While intricately related, aren't equivalent.
- tptacek 16y ago
  There is no browser vendor right now that isn't taking memory corruption vulnerabilities seriously. It isn't '99 anymore. We're not battling it out in the papers about "theoretical" vulnerabilities. When people report "possible code execution" without exploits, Microsoft sticks "possible code execution" in the MSRC alert. Somebody out there who has had a bad experience with MSFT is going to shellack me for saying that, but "getting vendors to take bugs seriously" is a really, really flimsy argument for a program that bribes researchers to bottle up their findings.
  - kenjackson 16y ago
    There are vulns that aren't fixed that by themselves don't seem so bad, but in conjunction with others are. And there are examples that aren't fixed today. For example, there's a disclosure of information bug in IE8 that exists, but you need the location of the target file to exploit it. If there's another exploit that lets you drop files outside the sandbox, and another exploit where you can overflow a buffer outside the sandbox on reading a file, you now have three vulns that together get you to run code, but any two of them is not sufficient. Note, I based this on SA38416, despite the fact that it appears possible/likely that this vulnerability actually doesn't exist as stated, but it was fine for expository purposes.