Vulnerability Disclosure 101

“Don’t hate the finder, hate the vuln” — @k8em0

Ryan McGeehan
May 8, 2015 · 7 min read

Goals

By the end of this article you should be able to critique both a fixer and a finders roles in a vulnerability disclosure to form an opinion on its strengths or where it broke down.

Image for post
Image for post
This WIRED article is an example of disclosure gone awry.

Assumptions

  • All software has numerous, undiscovered security vulnerabilities.
  • All developers trade between vulnerability and usefulness whether they know it or not.
  • Disclosure is impossible to get exactly right. We can cut people slack when honestly seeking “least harm”, since challenges exist in getting there for both fixer and finder.

Terms

This article describes a fixer and finder.

Ask These Questions

Is there clearly a fixer behind the bug?

When an fixer is clearly accountable, we can critique the finder in their decision to involve the fixer. We can also critique the fixer in their decision to cooperate with the finder.

Did the fixer invite vulnerability research?

A fixer could have a disclosure policy and / or bug bounty programs to actively invite research. A finding that goes through established disclosure channels to the fixer is very different from a finding that fell on deaf ears.

Was the fixer accessible?

Some fixer want findings sent through a myriad of email lists, bug trackers or customer service forms. The inward receipt of bug reports between developers are largely inconsistent, but all that matters is responsiveness. The vast majority of bug reports from well intentioned finders fall on deaf ears, so we should look for responsiveness on a fixers part as a positive sign.

Was the Finder a strong communicator?

Keep in mind that security and engineering teams face a signal / noise problem. At Facebook, we received many hundreds of reports a day, and stuff would fall through if there was a multi-page rant and preamble before getting to proof of concept.

Was the fixer responsive?

Once a valid submission is sent to a fixer, start a clock. If they’re a huge conglomerate with many products and reports to sift through, a reasonable lag shouldn’t be a big surprise. As examples, HackerOne suggests 30 days, CERT/CC permits 45 days, and Project Zero over at Google is a strict 90 days.

Image for post
Image for post

Did the finder adhere to a disclosure policy?

Disclosure programs typically ask for finders to confidentially submit vulnerabilities to fixer. For instance, if a finder told all of their friends on Twitter or published a blog post before disclosing to a fixer, they aren’t entitled to any special treatment in terms of bounty or fixer recognition. They’re more or less on their own and should expect no reward from the fixer.

Did the fixer come through?

Assuming everything goes well up to this point there should be an as-timely-as-possible fix released, the fixer has been communicating this progress to the finder, and whatever they’ve promised as far as a monetary reward, recognition, or whatever else has come through.

Was / Is the vulnerability exploited?

For particularly nasty vulnerabilities, the fixer ideally should have a level of confidence on whether a vulnerability was taken advantage of by criminals. If the finder took advantage of it (outside of their research) then that is straight up illegal.

Severity

We should only consider a panic for the highest severity vulnerabilities. Unfortunately, many disclosures become popularized when they’re not really putting many people at risk.

Probability

How simple is this to exploit, and what do I need to exploit it?

Impact

If exploited, what is the damage? Embarrassment? Stolen Credit Cards? Eavesdropping? Jail time for dissidents? Death?

Scale

How many people will be impacted by this, if exploited? Thousands? Millions? Ask about probable circumstances of exploitation.

Calibration

Let’s talk about what sorts of vulnerabilities and disclosures should be cause for concern.

No big deal

Vulnerabilities that are discovered and reported, fixed within a reasonable time with a healthy relationship between the fixer and the finder are no big deal. This happens all the time, are no big deal, and (strangely enough) are a sign of an extremely mature security program.

Improvements Needed

Vulnerabilities are discovered and reported with some delays or misunderstandings. Patches and workarounds might not work the first time. The fixer may have been hard to reach at first but eventually became somewhat responsive. The finder refused to give a proof of concept or made demands before providing it.

Totally Broken

The fixer is hostile to a vulnerability reporter. A bug is not fixed within a reasonable time. Cats and Dogs are living together. Patches are not available and people are being victimized or breaches are occurring, at an enormous scale. The finder didn’t bother to look at the disclosure policy or exploited it themselves instead of a proof of concept.

Conclusion

If you have developed technology that others depend upon — treat vulnerabilities as inevitable and have a process for resolving them promptly. Anything less is purely irresponsible. Many software developers have dismissed this responsibility in the past, but this is fortunately becoming much easier to manage.


@magoo

I’m a security dude. Former Facebook, Coinbase, Co-Founder of HackerOne, and currently an advisor and consultant for a handful of startups . Incident Response and security team building is generally my thing, but I’m mostly all over the place.

Starting Up Security

Guides for the growing security team

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store