OSVDB has just announced its Winter 2010 Fundraising Goal, which currently hopes to raise $9,000 before April 1, 2010. Looking back over the last couple of years of advances in the project, it’s easy to see not only how the project has evolved, but also how operational costs have increased to cover software development, content development, server hosting costs, and other assorted expenses to help keep OSVDB interesting, timely, and functional.
On an average, OSVDB has promoted 10,000 to 12,000 vulnerabilites per year for the last the last few years. Breaking that down to about 1,000 per month, the vulnerabilities in the database are gathered from a variety of sources, such as CVE, Secunia and various vendor changelogs and advisories. Keeping up a pace of about 1,000 newly listed vulerabilities per month hasn’t always been easy… but it’s about to get interesting.
I recently resigned my position as Chief Communications Officer with Open Security Foundation to focus more on the “content” aspect of OSVDB and DataLossDB. The extra time gained from giving up administrative duties will hopefully help the sites keep content fresh and accurate. Jericho, CJI, and I are going to keep working on new vulnerabilities as we can and keep the ball rolling.
With that said, I’m issuing a challenge: For every new vulnerability issued an OSVDB ID from January 1, 2010 through April 1, 2010, I will donate $0.50 (fiddy cents) of my own money to the OSVDB fundraiser. I challenge anyone who feels that OSVDB is a valuable resource to the security community to match my donation.
To make a few points clear:
- I am no longer an OSF officer. My donation comes out of my own pocket, not the OSF coffers, and I will accept no compensation from OSF for this offer. If I have to sell a kidney, I hear you only need one anyway.
- Since Jericho, CJI, and I are the ones who generally push new vulnerabilities to “live” status, there will be no slacking to save my bank account. If anything, I’ll be more motivated to push the potential donations higher and they’ll be motivated to watch me suffer on April 2. That’s how we roll.
- At an average of 1,000 vulnerabilities a month, over three months I expect to donate $1,500. It may be less, it may be more. There will be a maximum cap of $2,500 donated by myself and anyone who matches it. If we can push 5,000 vulns in three months, something is either very wrong or very great. YMMV.
- If five other people and/or groups take me up on the challenge and we meet our average, OSF will meet its goal. We still hope everyone else will contribute not only time but *effort* to help the project.
- This is not a gimmick. It’s not smoke and mirrors. You can see what OSVDB pushes on a daily basis on our Twitter page and on our contributors page. We will push all legitimate vulnerabilities just as we have been doing for years. If we’re slow for a few days, don’t worry. We’ll catch up.
So, that’s the challenge. If anyone wants to play and match my offer, please contact us at moderators[at]osvdb.org. I’m going back to work now.
I always mean to post changes more frequently, but apathy and other tasks seem to win the day. Here is a brief list of OSVDB change highlights over the past few months.
- The database currently covers 59,833 vulnerabilities, spanning 26,179 products from 4,735 researchers, over 44 years.
- Sequoia, ES&S and InkaVote e-voting machine audit documents integrated (all text search “electronic voting machine”)
- Happy 10th birthday CVE! We are now “fully” mapped for all years
- Integrated the historic Phage mail list content (http://securitydigest.org/phage/)
- Our Snort X-ref import script was borked (since Sep). Fixed, added almost 500 recent Snort IDs to references
- Apache bug system scoured, over 150 Apache vulns added from the last eight years (http://osvdb.org/ref/blog/apache-scouring.txt)
- Metasploit static references supported (https://blog.osvdb.org/2009/10/23/metasploit-reference-support-added-more)
- Exploit-DB references supported (http://www.exploit-db.com/)
- VuPEN references supported (http://www.vupen.com/)
- Many vulnerability and solution templates overhauled
- Search engine rebuilds are considerably faster, will auto-tweet when rebuilding (as it may affect search results)
- Reference search for full URL works
- Title search for multiple words fixed (was temporarily matching on some but not all words)
- New search filters and custom exports (https://blog.osvdb.org/2009/11/09/search-filters-custom-exports)
- Inverse search filtering enabled (https://blog.osvdb.org/2009/10/30/not-it)
- Search by CVSS scores (https://blog.osvdb.org/2009/10/28/search-enhance-by-cvss-score-or-attribute)
- Any search can be turned into a ‘Watch List’. Left nav menu has this option, new results are mailed to you as entered in the system
- New menu system (top and left nav)
- Twitter feed more actively used for project updates
- Twitter feed displays on front page
- ‘About’ page is updated, expect more static pages to be updated to better reflect project status soon
- CVSSv2 scoring support added, including:
- CVSS scoring history (historically track NVD, OSVDB and other sources)
- Anyone can submit scores for entries without CVE/NVD (over 13,000)
- Updating CVSS scores for entries without are worth .25 points for now, to encourage mangling
- Moderation system in place for submitted CVSS scores
- Creditee system overhaul (https://blog.osvdb.org/2009/11/21/creditee-system-overhauled)
- “Vulnerabilities in OSVDB disclosed by type by quarter” graphs added to front page
- More fixes to continue support for IE6. Don’t expect this to last!
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”.
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!
Using the ‘Advanced Search‘, you can now search the database by entering a CVSSv2 score range (e.g., 8 to 10) or by a specific CVSSv2 attribute (e.g., Confidentiality : Partial). To search for entries with only a 10 score, use the search range 10 to 10.
Using this search mechanism, we can see there are 3,217 entries in the database with a score of 10 and 9,266 entries that involve a complete loss of availability.
We hope this flexibility allows for even more refined searches to better help your project or organization. Stay tuned, this is one of many new search features planned.
OSVDB’s classification system is designed to categorize certain attributes of a vulnerability. This facilitates custom searches by a specific attribute, helps researchers develop metrics and gives a better picture of the vulnerability landscape. Until now, we’ve tracked if an exploit is ‘available’, ‘unavailable’, ‘rumored / private’ or ‘unknown’. While this was a good start for exploit status, it has quickly outgrown usefulness. Today, OSVDB overhauled the exploit classification to use the following:
- exploit public – A working exploit is publicly available.
- exploit rumored – An exploit is rumored to exist, but cannot be confirmed.
- exploit private – An exploit exists, but is not available to the public or in a commercial framework (e.g., vulnerability pre-disclosure groups like iDefense or ZDI, researcher developed but unreleased).
- exploit commercial – An exploit has been created and is available to customers in a commercial framework such as Canvas or CORE Impact.
- exploit unknown – The status of a working exploit is unknown.
In addition, we are moving one existing classification to the ‘exploit’ column since it is relevant to this category:
- exploit wormified – An exploit has been crafted to spread via ‘worm’ or ‘virus’.
As always, if you have suggestions or questions about the classification system, please mail moderators[at]osvdb.org!
In addition to overhauling the ‘exploit’ classification, additional touch-ups and reorganization has been done to the classification system. For volunteers that help mangle entries, watch out as items have shifted in flight. For users of OSVDB, these will be mostly cosmetic changes and should not impact searching.
- Disclosure column has been re-ordered
- Location column has been re-ordered
- Several locations have been touched-up. Use of ‘required’ is consistent now.
- Context-dependent – Moved from OSVDB to Location
- Mobile Phone expanded to include ‘Hand-held’ devices that may not be a phone
- Patch now includes RCS as some fixes are only available from CVS, SVN, etc.
- Removed ‘best practice’, no longer useful. We do not support SANS Top 20 x-refs any longer, since they don’t support the “20” in the Top 20.
- Removed ‘no solution’. Until we have more volunteers and timely updates for all entries, ‘solution unknown’ is more accurate.
- Removed ‘hijacking’ attack type. Obsolete, not really an attack type of its own.
Along with the score, we display the date that NVD generated it and give users a method for recommending updates if they feel the score is inaccurate. While this is long overdue, this is one of many CVSS related features we will be adding in the near future. For those wondering about the delay in adding CVSS support, the cliff notes answer is “we had reservations about the scoring system”. Back in 2005, Jake and I had a long chat with a couple of the creators of CVSS and brought up our concerns. Our goal was to create our own scoring system, but internal debate (and procrastination) lead to neither being implemented. Rather than creating our own system, we finally opted to use what has become an industry standard. Some of our planned CVSS score enhancements on the to-do list, no particular order:
- Method for adding our own CVSS score. There are thousands of entries in OSVDB that do not have a CVE assignment, and as a result, no NVD based CVSS score.
- A more robust moderation queue to handle proposed changes. This may optionally have a one-click method for us to notify NVD of our change so they may consider revising their score.
- Ensure the CVSSv2 score is part of the database dumps, available for download.
- Method for tracking CVSS score historically. As NVD revises their score, or we do, a user should be able to see the history of changes.
- Compare our/NVD scores with other public tools, display discrepancy if different. For example, if a Nessus plugin scores an issue differently than NVD, show both scores so users may consider which is more accurate.
- Track researcher generated CVSS score. While infrequent, some advisories provide scoring. If different than NVD, display the discrepancy.
As always, if you have ideas on how we could better handle CVSS scoring, or have additional ideas for features, please contact us!
Results of Mangle-A-Thon 2009
Mangle-A-Thon 2009 went very well. In addition to some 20 or so primary sources matched for DataLossDB, several volunteers managed to improve the “complete-ness” of OSVDB by over a tenth of a percent. That may not sound like much, but with over 58 thousand vulnerabilities in that database, a tenth of a percent (0.1% for you math types) is a huge help.
We would like to send an enormous “Thank You!” to all those who came and helped out. You did a service to the entire industry by lending your time and efforts. Another enormous “Thank You!” to Midnight Research Labs Boston for hosting the event. The venue was perfect, and your efforts both in planning the event, and contributing at the event were invaluable. Thanks again to Voltage Security for sponsoring the event and providing the food and drink; it made the 12+ hours achievable.
We would like to extend one last “Thank You!” to all those who not only mangled at the event, but went home and have since mangled some more. That is exactly what we had hoped for: a community contribution by and for the security community, and we hope you enjoyed the experience and will continue to work with us.
The success of the event may drive us to do another one (probably not until next year), maybe in a different city, or it might just and up right where we did it this time. Maybe we’ll have it happen across a couple cities next time! Let us know what you think… any suggestions are welcome!