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.
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.
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.
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.
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.
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.
I wish that there was some widely agreed upon standard for "considered harmful" articles. Like, they have to be serious problems. They can't just be nitpicks or of the "this will mislead the already clueless layman when the press gets wind of it" bent.
There are so many vulnerabilities and exploits developed every year. How can it matter very much if a small handful of them are rewarded more substantially and disclosed using a slightly different than normal procedure? Pwn2own considered a wash, if you ask me.
Wiktionary defines "nitpick" as "To correct minutiae or find fault in unimportant details." But "Go To Statement Considered Harmful" (http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.92....) is not about minutiae or unimportant details; it is about how to approach the task of writing a computer program that does what you want instead of something else, a task that is at the core of the modern economy.
It focuses on the largely insignificant debate over the merits of one syntax structure over another. It's essentially the vi versus emacs of programming.
There's a difference between a nitpick and a paper that basically defines a new programming paradigm (or delineates the need for it compared to another paradigm).
There are so many exploits developed every year. How can it matter very much if I disclose mine? Someone else will, I'm sure. They're all running the same JS fuzzer farms, after all. Who cares if Latvian organized crime gangs find it first? Someone good will find it eventually. Or at least reverse it out of the rootkits.
The problem isn't simply that the procedure is different. It's that the procedure is clearly, obviously, demonstrably sub-optimal. The Chrome bug-bounty, which Zalewski is surely involved with, runs year-round. The incentive is, you find something, you file it with them ASAP before someone else does. The same is not the case with CanSec's Pwn2Own, where, for no reason other than marketing for ZDI and CanSec, disclosure happens at one precise time during the year.
I disagree. While Pwn2Own is not evidence of the relative security of browsers, I don't see how it can be "harmful" when it causes Google and Apple to find and ship numerous fixes for the competition. It also raises awareness to the general public; if IE 8 being hacked at Pwn2Own gets even some of the less technologically-inclined to switch to a better browser, I'm all for it.
It creates a powerful incentive not to disclose vulnerabilities within a large window of time preceding CanSecWest (disclose now: $0; disclose in March: $15,000), and it creates false perceptions about the relative security of browsers and about security in general.
The argument against Pwn2Own is pretty straightforward.
Incidentally, switching from IE for security is tricky. There are some (v. popular) browsers you could switch from IE to that (the C.W. says) would make you more secure; others, less. The IE family has a lot of problems, but "owned by people who don't give a shit about security" isn't one of them.
I do agree with this quote from the article: "it is in the interest of the conference and contest organizers, and the participating researchers, to get publicity for their findings - and journalists, who do not necessarily have a holistic view of the day-to-day browser security research, embrace such high-profile developments with disproportionate enthusiasm."
I always hate reading reports from Pwn2Own every year - "browser y was exploited in less than x seconds!!11!" As the article points out, not only is this very misleading (you might say downright false), this kind of sensationalist journalism trickles down and misinforms the general public about the state of browser security.
Pwn2Own is harmful. Jon Oberheide's article[1] convinced me of that. Bug bounties encourage the disclosure of vulnerabilities as soon as they're discovered; contests like Pwn2own, with specific starting dates, encourage the accumulation of undisclosed vulnerabilities until the contest begins. It unnaturally extends the lifetime of bug, and hurts users by leaving them vulnerable for longer than necessary.
The author makes some valid points. However, I'm not convinced that Pwn2Own is overall a bad thing, for 2 reasons:
1. It is far more public than bug bounties. The browsers that get hacked are in the public spotlight, and that can pressure them into doing a better job in the future.
2. The browsers that put the most effort into security - Firefox and Chrome - did well this year. The article and comments seem to imply this might be a coincidence. There is some element of chance here, so it's possible, however, I don't agree that chance is a major factor. Furthermore, if it was as easy to hack browsers as the article implies, you'd expect all the browsers to be hacked - again arguing against randomness being a big factor here.
The key point is that there are dozens of serious vulnerabilities found in Firefox and Chrome every year. The availability of a vulnerability at an exact time in an exact place is not a good way to compare such broad trends.
27 comments
[ 3.1 ms ] story [ 95.9 ms ] threadI 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.
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.
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.
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.
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.
There are so many vulnerabilities and exploits developed every year. How can it matter very much if a small handful of them are rewarded more substantially and disclosed using a slightly different than normal procedure? Pwn2own considered a wash, if you ask me.
The problem isn't simply that the procedure is different. It's that the procedure is clearly, obviously, demonstrably sub-optimal. The Chrome bug-bounty, which Zalewski is surely involved with, runs year-round. The incentive is, you find something, you file it with them ASAP before someone else does. The same is not the case with CanSec's Pwn2Own, where, for no reason other than marketing for ZDI and CanSec, disclosure happens at one precise time during the year.
The argument against Pwn2Own is pretty straightforward.
Incidentally, switching from IE for security is tricky. There are some (v. popular) browsers you could switch from IE to that (the C.W. says) would make you more secure; others, less. The IE family has a lot of problems, but "owned by people who don't give a shit about security" isn't one of them.
I always hate reading reports from Pwn2Own every year - "browser y was exploited in less than x seconds!!11!" As the article points out, not only is this very misleading (you might say downright false), this kind of sensationalist journalism trickles down and misinforms the general public about the state of browser security.
Terrible headline and approach to the subject, imo.
[1] http://jon.oberheide.org/blog/2011/03/07/how-i-almost-won-pw...
1. It is far more public than bug bounties. The browsers that get hacked are in the public spotlight, and that can pressure them into doing a better job in the future.
2. The browsers that put the most effort into security - Firefox and Chrome - did well this year. The article and comments seem to imply this might be a coincidence. There is some element of chance here, so it's possible, however, I don't agree that chance is a major factor. Furthermore, if it was as easy to hack browsers as the article implies, you'd expect all the browsers to be hacked - again arguing against randomness being a big factor here.