Notarized Advisories: Prove You Found Something Without Giving Up Secrets

Thomas Ptacek | September 6th, 2006 | Filed Under: Disclosure, Uncategorized

You’ve discovered a new vulnerability in your Internet-enabled toaster. You’ve notified the vendor, but there’s no patch in sight. You’re a security researcher, building a reputation, and ego, control, and competition are kicking in. What to do?

Notarize the discovery.

Create an archive of your materials. Or just take a complete, detailed advisory. Sign it with a key you’ve published. Hash it. Publish the hash: 

Vulnerability in Internet Toaster 
Findings: 4db191015a5abedd90eace032ad88e154bc64e9d

Seven years from now, when Internet-enabled toasters become the new frontier for attackers and toaster findings are a hot commodity, you can demonstrate precisely what you found and (roughly) when. You simply publish exactly what it was you hashed. If the hashes match, you’re probably telling the truth.

Disclosure doesn’t always take place all at once. A trend started by eEye is to publish a “vendor” timeline: 

Remote code execution vulnerability in Toastmaster TTOB4RL: 
170 days since notification

So, you can create two hashes, one for the vendor and product, and one for the actual discovery. Be careful, though: vendor/product is a trivial dictionary attack. One cheap solution is a keyed hash: for each disclosure, create a random key SHA1(nonce):

head /dev/urandom | openssl sha1 > key

Keep that secret. Now the vendor/product hash is SHA1(SHA1(nonce), Vendor, Product):

(cat key; echo "Toastmaster"; echo "TTOB4RL") | openssl sha1

Publish that hash:

Remote code execution vulnerability
Target: 55b4e84ae7165c09b1e5b4e217b1d59375698ab2
Findings: 2d0e23b6de9f4fc1e5527225623514a49ffa24bf
170 days since notification

When it’s safe, you publish the key, the vendor, and the product; any third party can verify your claim:

Remote code execution vulnerability
Product: Toastmaster TTOB4RL 
Key: 6d372e8de5ba4a3d460deb9d3287c736995266c9
Target: 55b4e84ae7165c09b1e5b4e217b1d59375698ab2
Findings: 2d0e23b6de9f4fc1e5527225623514a49ffa24bf
170 days since notification

The obvious challenge in this system is that it isn’t worth much without a trusted timestamp and a secure archive of hashes. Oh well. You can have trusted peers RSS your “anonymized advisories”. Or you can just wait to land in the Google cache. You’re just trying to accomplish two things:

  • An easy way to credibly list your findings without giving up secrets.

  • A method of doing that which makes it difficult to alter your claims later, or conversely, easy to get caught if you try it.

Vulnerability researchers routinely land in sticky situations that try their credibility. This makes some of them (like, say, us) gun-shy about publishing our progress on getting things out. “Notarized” advisories seem like a viable tool for solving that problem. What do you think?

Like many good ideas we talk about, this one didn’t really come from us. DJB uses a similar idea when he publishes papers, and Dave Aitel has apparently talked about this too.

Viewing 21 Comments

Trackbacks

close Reblog this comment
Powered by Disqus · Learn more
blog comments powered by Disqus