1

I am conducting a study about the different vulnerability disclosure policies in an effort to determine how long it takes for a given vendor to issue a fix/patch, depending on how a given vulnerability was disclosed. The problem is, I have a hard time to identify "fully disclosed" vulnerabilities (vendor was not notified prior to public disclosure). It seems that responsible disclosure is the norm nowadays, to the point that when a security researcher does not notify the vendor and fully discloses a vulnerability, people go crazy about it (this tweet and all the articles that followed). Note that I am not an advocate of either policies, I am simply conducting research as objectively as possible.

Does anybody know if it is possible to retrieve all vulnerabilities that were published following a full disclosure policy? Maybe someone out there has done this apparently tedious work and is willing to share it :) Or there is a website / tool that I don't know about that does just that.

If not, I guess I would have to look at each vulnerability entry (for a given vendor, of course), analyze the disclosure timeline (if any), find out when the patch was issued, and if vulnerability disclosure and patch release turn out to be on the same day --> responsible disclosure, and if patch release is on a later date --> full disclosure (or the vendor went past the 45 days deadline from CERT, for instance). Time consuming? Definitely. Realistic? Probably not. But would the results be accurate in your opinion?

Thanks!

2 Answers 2

4

One of the methods you can use to create a baseline would be to go to sites like PacketStorm find say the last 50 vulnerabilities/exploits disclosed, then find out whether or not they have CVEs issued on Mitre. A baseline will give you just that, a baseline average. There are a few things to take into considerations:

  1. Not all exploits/vulnerabilities are always disclosed by researchers or vendors
  2. Not all vulnerabilities/exploits end up having a CVE

In regards to #1, I have CVEs issued to me for vulnerabilities that although the vendor has patched, I didn't see a need to start writing vulnerability disclosures to send to full disclosure, bugtraq, or other similar sites. This is usually for a few reasons 1) I am too busy to be bothered 2) there is no fix and therefore no need to raise the level of attacks (if someone else finds it, so be it) 3) vendors can be 'tough' to deal with. I once reported a vulnerability to a networking equipment manufacturer, and it took them 2 years to fix. This consisted of weeks on end of me giving away free time explaining things, re-testing, and so forth.

As for your other comments: "Same day patch" is non-existent. Any company willing to put forth a patch in one day would be doing so recklessly. Programmers need to ensure legacy applications can still function, and things aren't broken with a patch/update/fix. This is a time consuming process, and any application development house has processes and policies in place that follow rigorous testing/fixes. As for the '45 day' disclosure this is not set in stone:

Q: Will all vulnerabilities be disclosed within 45 days? A: No. There may often be circumstances that will cause us to adjust our publication schedule. Threats that are especially serious or for which we have evidence of exploitation will likely cause us to shorten our release schedule. Threats that require "hard" changes (changes to standards, changes to core operating system components) will cause us to extend our publication schedule. We may not publish every vulnerability that is reported to us. http://www.cert.org/vulnerability-analysis/vul-disclosure.cfm?

Good luck with your research, at best I can see you only getting a baseline. There are too many variables, and the output may be tainted. For example: Microsoft, Cisco, and other big name vendors may be targeted as "stellar" or "unappealing" but what are you comparing them to? myjoomlasoftware.v1, or myhomebackedGitHubProject2.0? Open source, closed source, big vendor, small vendor, petprojects, githhub? These are things to take into consideration, either of which can skew your data immensely.

1
  • Thank you for your input! Going through PacketStorm sounds like a good approach. With "Same day patch", I did not mean that the vendor would create and issue the patch in a single day. What I meant is that the disclosure timeline of a vulnerability is not always known, but what we can do is check when the patch/fix was made public, compare it to the vulnerability's public disclosure date, and if the patch was issued earlier or on the same day, it is fair to assume that the vulnerability was responsibly disclosed to the vendor, and public disclosure only happened once the patch was ready.
    – AleVe
    Commented Jun 28, 2016 at 16:45
1

Honestly it really depends on the company. Every company handles their vulnerabilities differently, even some researchers who follow the process get screwed by it, just like this guy who filed a bug for Instagram.

For those entered through the bug bounty program (if they have one), they will generally publish the information on their site or email to the chain of users subscribed to the program. Otherwise you're going to have to stringently follow many companies to get this information.

You may also try emailing their teams to see if they will provide a list to you as a researcher, depending on the level of information you require, some teams will do so if it is in their culture, but many will see this as Social Engineering, and may deny your request.

I would also take a look at BugCrowd, which provides a list of companies with bug bounty programs and the links directly to the appropriate pages.

If anybody has done this work, that would be great, but it's a lot of information to consider so good luck!

2
  • 1
    An awesome read indeed. Thank you! I've never been involved in a bug bounty program, do members really get first-hand (or let's say, extra) information about vulnerabilities found within the program? It surely varies among programs, but if yes, would you happen to know which ones?
    – AleVe
    Commented Jun 28, 2016 at 16:39
  • Thanks! Well the point is that independent members of the platform and/or community search for bugs and submit them, for which they are fully involved in the process to not only describe the problem (software bug or security vulnerability), but to help resolve the problem if they can). They probably only get pertinent information. Unfortunately I do not know of any such programs by name.
    – signus
    Commented Jun 28, 2016 at 18:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .