This is a much more complicated answer than the industry standard, which is to post a SHA-1 hash of a summary of your exploit, along with (sometimes) the vendor name. I'm not sure how important the extra problems that this solves are.
Yes, it allows a vendor to "prove" they fixed a vulnerability. Perhaps if you're looking at vulnerability research as an outsider you think this is a significant issue. But it really isn't. If Chris Valasek or Tavis Ormandy say that (say) Adobe hasn't fixed their finding, everybody (including Adobe) will believe them. On the flip side, when Adobe fixes Valasek or Ormandy's bug, they're going to say that right away. Believe it or not, vulnerability researchers like it when vendors fix their bugs; it's part of how you keep score.
And even if you think proving vulnerabilities is a real issue, all this does is allow vendors to decide autonomously to prove something. But vendors don't need tools to do this, and neither do researchers. The real problem is that vendors sit on vulnerabilities for months or years; giving them one more (complicated) way to publish doesn't really help much. Meanwhile, the researcher can disclose any time she wants; she justs posts the exploit to Pastie or F-D. Done and done.
And yes, this creates a central location for customers to see outstanding security issues with products. But Zed can do that right now without getting researchers to do anything differently. He can just follow security researchers on Twitter and RSS their blogs and wait for them to post things. Then he can create entries on his site. Charlie Miller even posts numbers, like, "I have 193882 binned crashes in Quicktime and Apple has fixed none of them so far". Some visualization tools might come in handy. It's less fun than crypto schemes, but probably more useful.
Also worth mentioning: there already are "vulnerability arbitration centers" that do exactly this. Also, they take over the project management with the vendor. Also, they publish formal advisories to alert the public. Also, they pay the researchers. Sometimes a lot. One of them is TippingPoint's Zero Day Initiative, which also runs the annual Pwn2Own contest at CanSecWest. Another is iDefense.
Finally, you can consider whether this addresses the problem of "how do I communicate a vulnerability securely to a vendor". That is indeed a real problem and this is indeed a viable answer to that problem. But every vendor that has a vulnerability response process already has a secure channel for receiving reports. From spending the last 5+ years of my life communicating findings to vendors who don't have that process in place, let me assure you that "secure channel" is the least of your problems. Forget getting your email intercepted; worry more that your finding is going to end up in the vendor's public bug database tagged as a "feature" (seriously, go pick a slightly non-mainstream vendor with a public database and do searches for "segmentation fault" or even "nessus", as in "bug: product crashes and reboots when nessus is run against it").
---
If, as a vendor, you want to do something to streamline vulnerability reports, run - do - not - walk to create this web page on your site:
I highly recommend you just crib from what 37signals did.
If you don't, and rely instead on the notion that a researcher could in theory use the RSA key in your SSL cert to send you a secure message, please bear in mind that many --- perhaps most --- researchers will interpret your lack of guidance on this as a license to simply publish your flaws directly on a mailing list. You didn't, after all, tell them not to, or tell them where they should instead send their findings.
> The real problem is that vendors sit on vulnerabilities for months or years; giving them one more (complicated) way to publish doesn't really help much.
Just making sure you actually read what I wrote, since that's specifically stated as the problem being solved, and at the top of the site it says researchers publish vulnerabilities, not the vendors. I think you misunderstood and think the vendors publish these.
Not replying, just making sure I understand that you read what I wrote and what you're actually saying in your statement above.
First, thanks for the careful response. You and I argue in much the same manner as pure sodium argues with water. You're being nicer than I am this time.
Second, the point of posting a catalog of vulnerabilities encrypted under the RSA keys of vendor SSL certificates is that the vendor can authenticate a posting; the vendor, after all, is the only party that can decrypt them. I think we're clear on who the actors are here.
You appear to be trying to build a system that exerts pressure on vendors to fix and publish security findings by allowing researchers to safely claim publicly that they have findings.
But researchers already have several tools for doing this. One of those tools (my least favorite) is things like the ZDI, where you are paid hundreds or thousands of dollars to let a big company handle the problem for you. Another popular solution that has the virtue of simplicity is, again, simply posting a SHA-1 hash of your finding, like, "ad1ad1ccb6da145406edef884e0595b4b1f5c4ae IE8".
The latter solution is exactly as amenable to pressuring vendors as "vulnarb.com" is. You can even help. Just collect and aggregate those reports. No public key cleverness is required.
My read on you --- and please take this as a compliment --- is that you are a cleverness junkie. The trick of sending encrypted messages using SSL certs instead PGP or S/MIME is indeed clever. But not every clever solution serves a real problem.
Yep, you know way more about this than I do. I've wanted to solve this problem for a while so any feedback helps.
The only thing you seem to be missing in the above is the consumers. It's not about getting the vulnerabilities transmitted to them, it's about posting that they exist, who did them, how severe they are, and in a way that can be verified by all three parties.
AFAIK, I can't currently go do that with ZDI right? They're sort of paid to keep this secret.
As for gathering existing SHA1 hashes, I'll look into that. Could be a way to seed the database ahead of time.
And no, I'm not a cleverness junkie. I mean, it's a shell script that's like 8 lines long. I just saw a problem in getting a vendor's "public key" and then realized I could do it this way.
How does this SHA-1 hash come full circle? Everybody on the web will know that I hashed something. The vender knows that I hashed the findings I sent to them, but so what? Do I have to post the hash on my own domain, so the vender knows that the findings they received are from the same person who owns the domain where the hash was posted?
Subtracting "reputation" as a requirement in that equation has to have at least a small positive value, doesn't it? I don't know how many independent researchers there are who have a chicken-and-egg problem with reputation because they don't know how to disclose both visibly and responsibly. But if there are any, Zed's method seems beneficial.
I think point of hashing is to prove that researcher has indeed found the vulnerability first and reported it to the vendor. It is proof for "this summary was written by me 2 months ago".
Hash must be posted to some archived/public place (tweet, mailing list, etc) that can be referenced at later date when actual summary is released.
I should have been clearer. Researchers post SHA-1 hashes publicly (if they care). They send the actual details directly to the vendor. The vendors you care about publish PGP keys. The ones who don't can't really be trusted to handle security advisories anyways. No, really: they really do put them in their public bug databases!
What made the vulnarb.com idea interesting is that by combining the two actions: a safe public notice and a secure vendor communiation --- you could create a public clearinghouse that consumers can consult to see if (say) Google is holding back on disclosures.
The issue here is, you don't need an elaborate crypto scheme to do this. Tavis Ormandy doesn't have to post an encrypted bundle anywhere to notify the public that he has a new Microsoft bug. He can just say "I have a new Microsoft bug" on Twitter. Reputation is so compelling that really, nobody bothers even posting SHA-1 hashes anymore. If you work for a credible vuln research shop and you post a message saying you have a finding in Adobe Reader, you have it. Case closed.
Zed could build the aggregator for these reports if he wanted to. It would be valuable. But that's just data entry. Zed programs. I don't blame him. I program too. I wouldn't want to build that site either.
> Tavis Ormandy ... can just say "I have a new Microsoft bug" on Twitter.
You're right, but what about the nobodies that haven't built up a personal trophy case of exploitable bugs? vulnarb.com may be solving a problem that doesn't exist for people that are already at the top of the vulnerability researcher club, but as with any group of people, there are hundreds if not thousands of people that aren't known and don't care to be the "l33t" ones giving conference talks and swapping private keys with Schneier and Knuth.
This could be a gateway for those people, college students and unknown hackers from non-first world countries (the alleged comodo hacker types for instance), to responsibly and legitimately get into the field. If marketed right, vulnarb.com could be a perfect way to post these notices, without getting trolled to oblivion on F-D.
Sorry I deleted my comment just as you posted. Thanks for the explanation.
Here is the deleted comment:
How does a vendor go from said SHA-1 hash to what the vulnerability is?
I saw this as a rough draft for a way to easily publish vulnerabilities without letting the public view them but still letting the vendor have all the information.
Yes, it allows a vendor to "prove" they fixed a vulnerability. Perhaps if you're looking at vulnerability research as an outsider you think this is a significant issue. But it really isn't. If Chris Valasek or Tavis Ormandy say that (say) Adobe hasn't fixed their finding, everybody (including Adobe) will believe them. On the flip side, when Adobe fixes Valasek or Ormandy's bug, they're going to say that right away. Believe it or not, vulnerability researchers like it when vendors fix their bugs; it's part of how you keep score.
And even if you think proving vulnerabilities is a real issue, all this does is allow vendors to decide autonomously to prove something. But vendors don't need tools to do this, and neither do researchers. The real problem is that vendors sit on vulnerabilities for months or years; giving them one more (complicated) way to publish doesn't really help much. Meanwhile, the researcher can disclose any time she wants; she justs posts the exploit to Pastie or F-D. Done and done.
And yes, this creates a central location for customers to see outstanding security issues with products. But Zed can do that right now without getting researchers to do anything differently. He can just follow security researchers on Twitter and RSS their blogs and wait for them to post things. Then he can create entries on his site. Charlie Miller even posts numbers, like, "I have 193882 binned crashes in Quicktime and Apple has fixed none of them so far". Some visualization tools might come in handy. It's less fun than crypto schemes, but probably more useful.
Also worth mentioning: there already are "vulnerability arbitration centers" that do exactly this. Also, they take over the project management with the vendor. Also, they publish formal advisories to alert the public. Also, they pay the researchers. Sometimes a lot. One of them is TippingPoint's Zero Day Initiative, which also runs the annual Pwn2Own contest at CanSecWest. Another is iDefense.
Finally, you can consider whether this addresses the problem of "how do I communicate a vulnerability securely to a vendor". That is indeed a real problem and this is indeed a viable answer to that problem. But every vendor that has a vulnerability response process already has a secure channel for receiving reports. From spending the last 5+ years of my life communicating findings to vendors who don't have that process in place, let me assure you that "secure channel" is the least of your problems. Forget getting your email intercepted; worry more that your finding is going to end up in the vendor's public bug database tagged as a "feature" (seriously, go pick a slightly non-mainstream vendor with a public database and do searches for "segmentation fault" or even "nessus", as in "bug: product crashes and reboots when nessus is run against it").
---
If, as a vendor, you want to do something to streamline vulnerability reports, run - do - not - walk to create this web page on your site:
http://news.ycombinator.com/item?id=804257
I highly recommend you just crib from what 37signals did.
If you don't, and rely instead on the notion that a researcher could in theory use the RSA key in your SSL cert to send you a secure message, please bear in mind that many --- perhaps most --- researchers will interpret your lack of guidance on this as a license to simply publish your flaws directly on a mailing list. You didn't, after all, tell them not to, or tell them where they should instead send their findings.