Thanks to Dave, we now have a completely re-written creditee system. For years, we operated off a four field system (name, email, company, url) for tracking vulnerability researchers. While we tracked that information, it was not flexible and led to serious problems with data integrity. Even worse, it didn’t allow for long term tracking of a researcher’s disclosure history. There were several cases where the system couldn’t handle proper data tracking, for example:
- If John Doe works for CompX and discloses a vulnerability, that becomes set in stone as associated with his name. This is problematic if John Doe goes to CompZ and discloses additional vulnerabilities.
- The above scenario is even more problematic if John Doe then releases a vulnerability through a program such as iDefense or ZDI.
- If two researchers shared the same name, there was no way to differentiate them.
While creating a creditee system to track this may seem straightforward, it is surprisingly difficult. After a lot of brainstorming and trying to determine where the system may fall short, we came up with something. What we are now referring to as “creditee v2” will be used with a clean set of data. All previous creditee data entered is labeled (internally) as “v1” and will only display if there is no v2 data.
The new creditee system is a bit more complex, but allows for one individual to be associated with multiple e-mail addresses, companies or organizations. We can also now track the country of the researcher and company separately to account for multi-national companies. With a better data set, we can now do a lot more analysis and generate interesting statistics for vulnerability researchers. As an example of the new system, you can now easily see all vulnerabilities associated with your name, e-mail addresses and affiliations. Clicking on the affiliation will show all researchers and the vulnerabilities disclosed by a given organization.
Even better, this system allows for one click access to your prior vulnerability disclosures. This could be useful for resumes, web page bios and more. We fully encourage you to “ego mangle” to help us fill in the data. Create an account, find your vulnerabilities in the database and fill in the details associated with that disclosure. Note: we are tracking the information associated with the disclosure, not necessarily your current e-mail or affiliation. If you can’t find your vulnerability in the database, mail moderators[at]osvdb.org with details. We’ll help you find it or add it in case it is missing. We’re still working out several bugs in the system, but this is a great overhaul and a foundation of another long term feature enhancement: “researcher confidence”.
Earlier this evening, there was a Twitter debate regarding a proposed standard for responsible vulnerability disclosure. It referred to ISO/IEC 29147, a proposed standard for responsibly disclosing a vulnerability. @dinodaizovi brought up a fresh angle, that the “responsible disclosure” name itself completely ignored the aspect of the vendor practicing “responsible remediation”. That term should really be more in the center of our minds and discussion. The lack of “responsible remediation” is why so many researchers are fed up with dealing with vendors. That is one reason some use services like ZDI or iDefense, not just the cash.
The “responsible disclosure” debate is stale for the most part. We’ll never agree on how much time is ‘right’ for a vendor to fix a vulnerability. Some researchers think it’s days, other think weeks or months. In the paraphrased words of some female vendor on some boring responsible disclosure panel a few years back, “if i can have a kid in 9 months, i should be able to fix a vulnerability too“. Yet 9 months isn’t reasonable to some vendors like HP, who routinely break the 1,000 day mark, even for simple XSS.
@mckeay brought up another aspect to the responsible disclosure debate that was actually fresh, asking what part consumers played in the disclosure process. While I believe it is a neat aspect and something most haven’t considered, I personally believe it is quickly answered by “consumers can put financial pressure on vendors that don’t play well with others”. In reality, consumers are lazy. It takes more than a few bad acts to get us to spend time an energy finding a new vendor. Short of anally raping us with a router and pouring lemon juice in our festering wound, nine times out of ten, we will not find a new vendor.
Back to @dinodaizovi. He is right, any standard for disclosure should be equally centered on the vendor as it is for the researcher. Researchers can easily fall back on RFP’s “rfpolicy” disclosure policy and change X days to something they believe in. The framework is still perfectly valid and outlines the process, the time frames are always up for debate.
What if we carried this one step beyond? How about making the ISO standards apply to any and every vulnerability, regardless of who found it? If BigVendor finds a vulnerability during internal testing and fixes it, don’t consumers have a right to know? When BigVendor says “upgrade to Service Pack 18” and only gives us a reason of “big stability enhancements!!”, shouldn’t we have a right to know those enhancements translate into 17 remotely exploitable vulnerabilities discovered during internal testing and QA? Wouldn’t *that* knowledge be a more significant reason to upgrade and apply the service pack?
I realize it is a pipe dream to think that most vendors would ever offer that level of transparency, even months (years?) after a given issue is fixed. In reality though, they are the proverbial large mythical flightless birds who stick their heads in the sand rather than face a difficult situation (ostriches are real and don’t bury their heads). It has been proven countless times that serious vulnerabilities in big vendors (e.g., Microsoft, Apple, Adobe) are being discovered by multiple parties. No one with an inkling of common sense and rational thinking can believe that the ‘bad guys’ aren’t also discovering some of these bugs. We’re long past the point of vendors honestly thinking that they can get away with some notion that they have a reputation for ‘security’. Add it up, and we’re to that time where the big vendors should be disclosing vulnerabilities discovered during their internal QA / SLDC process. The reputation of insecure software really can’t hurt them any more, and transparency is finally the one thing that could buy back some degree of consumer confidence.
Perhaps now is the time where ‘responsible disclosure’ should apply equally to hackers, security researchers and vendors, as well as apply to ‘responsible remediation’. Because really, some 20 years after the disclosure debate got going, do we really think we need to try to apply more guidelines to researchers giving away $250/hr consulting work or “hackers” posting vulnerabilities as a hobby? Vendors that have tried to label or apply policy to these people were simply blame-shifting from day one, while not applying that desired policy to themselves.
Last week, OSVDB enhanced the search results capability by adding a considerable amount of filter capability, a simple “results by year” graph and export capability. Rather than draft a huge walkthrough, open a search in a new tab and title search for “microsoft windows”.
As always, the results will display showing the OSVDB ID, disclosure date and OSVDB title. On the left however, are several new options. First, a summary graph will be displayed showing the number of vulnerabilities by year, based on your search results. Next, you can toggle the displayed fields to add CVE, CVSSv2 score and/or the percent complete. The percent complete refers to the status of the OSVDB entry, and how many fields have been completed. Below that are one click filters that let you further refine your search results by the following criteria:
- Reference Type – only show results that contain a given type of reference
- Category – show results based on the vulnerability category
- Disclosure Year – refine results by limiting to a specific year
- CVSS Score – only show entries that are scored in a given range
- Percent Complete – filter results based on how complete the OSVDB entry is
Once you have your ideal search results, you can then export them to XML, custom RSS feed or CSV. The export will only work for the first 100 results. If you need a bigger data set to work with,
we encourage you to download the database instead.
With the new search capability, you should be able to perform very detailed searches, easily manipulate the results and even import them into another application or presentation. If you have other ideas of how a VDB search can be refined to provide more flexibility and power, contact us!
This post is the farthest thing from picking on or insulting CVE. They were running a VDB some four years before OSVDB entered the picture. More impressive, they operated with a level of transparency that no other VDB offered at the time. Early OSVDB entries suffered just as greatly as the early CVE entries, and we even had the benefit of four years to learn from their efforts. Reading the original CVE entries is a fun look at how it all began. This post is a brief light-hearted look at the past.
http://cve.mitre.org/cgi-bin/cvename.cgi?name=1999-0345 – CVE contributors can be stumped
http://cve.mitre.org/cgi-bin/cvename.cgi?name=1999-0465 – Client side vulnerabilities aren’t an issue.
http://cve.mitre.org/cgi-bin/cvename.cgi?name=1999-0285 – No reference, no problem!
http://cve.mitre.org/cgi-bin/cvename.cgi?name=1999-0549 – ISS tried desperately to help.
http://cve.mitre.org/cgi-bin/cvename.cgi?name=1999-0684 – A CVE entry can be a duplicate of itself.
http://cve.mitre.org/cgi-bin/cvename.cgi?name=2000-0151 – We miss colorful CVE commentary.
Vulnerabilities reported ten years ago, they have no impact on your customers. If they do, then you are woefully behind and your customers are desperately hanging on to legacy products, scared to upgrade. For vendors who have kept up on security and adopted a responsible and timely manner for handling security, open up your records. Share with the world the ten or more year old vulnerabilities. Let the security community get a better picture of the real number of vulnerabilities reported to you, specifically the ones that never appeared in your advisories. This includes off-beat denial of service crashes, difficult to reproduce memory corruption, silly issues that required some level of access to begin with and everything else.
Some researchers have begun to do this, sharing more details of older disclosures that had vague details. Simple Nomad posted earlier this year about several old bugs as well as cleared up some confusion (via e-mail) regarding the old Palmetto FTP vulnerabilities.
I know this is a pipe-dream, as companies don’t want to admit to the number of vulnerabilities in their products, even ten years ago. Doesn’t matter that they fought uphill battles to win over the media and consumers with promises of how their software development life cycle matured or how they learned from their past. No way a vendor will dump hundreds of previously unpublished vulnerabilities on the world. On the rare chance a vendor will realize this can only help their reputation by sharing information and contributing to the VDB and metrics communities.. send them in! moderators[at]osvdb.org