I’m so far behind in my daily routine and missed Thomas Ptacek’s post on Vuln Research In Numbers. Fortunately, Dave Aitel referenced the blog entry which prompted me to check it out. I so desperately want Ptacek to run his numbers against a complete OSVDB data set, but alas, I know that we do not have a complete data set for 2004. Symantec’s BID database has some problems with consistancy, citing sources (aka provenance) and missing vulnerabilities (which plagues most VDBs to one degree or another). In my mind, OSVDB tends to be more complete than most VDBs and maintains a creditee field, but due to a lack of volunteers we just don’t have enough entries public for him to do the same generation of statistics. Some day maybe! Until then, this is a very neat post with a different slant.
CodeScan Labs recently disclosed that their new product was used on ASP Portal to look for vulnerabilities. These types of scanners are automated and check for common programming errors that lead to vulnerabilities. These types of tools have been around for many years, but are starting to mature quickly. However, one has to wonder just how effective they can be:
2006-03-02 – ASP Portal announces version 3.1.0 which contains “CodeScan security fixes”
2006-03-03 – ASP Portal announces version 3.1.1 which contains “a critical security Fix” (in news_item.asp)
2006-03-14 – CodeScan discloses their tool found 10 SQL injections and over 50 cross-site scripting vulns
2006-03-20 – nukedx releases a working exploit for an SQL injection (in download_click.asp)
2006-03-21 – nukedx releases details for 10 SQL injections in 3.1.1 including one in news_item.asp
So CodeScan finds 10 SQL injections, but doesn’t find the 11 others that nukedx finds a week later, and doesn’t find the “critical” issue in news_item.asp either. Hopefully these tools continue to mature very quickly. Maybe some day, cross-site scripting vulnerabilities will be a thing of the past! Hah yeah right, if that were true, overflows and race conditions wouldn’t pop up every few days either.
The Open Source Vulnerability Database (OSVDB), a project to catalog and describe the world’s security vulnerabilities, has had a challenging yet successful year. The project is fortunate to have the continued support of some devoted volunteers, yet remains challenged to keep up with the increasing number of vulnerability reports, as well as work on the back-log of historical information. Volunteers are continually sought to help us achieve our short and long-term goals.
Despite resource constraints, there have been many exciting successes in 2005:
- A major project goal of obtaining 501(c)3 non-profit status from the U.S. IRS was achieved. Obtaining non-profit status was critical to the long-term viability of the project. This status allows OSVDB to take charitable donations to help cover operating expenses, while providing a tax benefit to donor companies and individuals.
- The vulnerability database has grown to over 22,000 entries thanks to the dedicated work of Brian Martin, OSVDB Content Manager. At the end of December, over 10,000 of those vulnerabilities were worked on by volunteers to provide more detailed and cross-referenced information. Our volunteer “Data Manglers” and Brian have helped ensure OSVDB is the most complete resource for vulnerability information on the Internet.
- OSVDB started a blog in April, as a way for us to keep the public better informed on the project’s status. Very quickly we realized the blog was a perfect place to discuss and comment on various aspects of vulnerabilities, and has become a successful mechanism for communicating with the security industry. If you have suggestions for topics, or would like to join the discussion, please visit the OSVDB blog.
We would like to also recognize our sponsors and thank them for their support. Digital Defense, Churchill & Harriman, Audit My PC, and Opengear have all provided important resources to OSVDB over the past year. We would also like to thank Renaud Deraison of the Nessus Project and HD Moore of the Metasploit Project for their support. Lastly, we of course want to thank our volunteers, and note that several of them have contributed to Nessus Network Auditing, available from Syngress Publishing.
We are very pleased with the progress and growth of OSVDB over the past year, but do not want to downplay the importance of recruiting new volunteers, as well as retaining our current ones, in order to get through the considerable back-log of vulnerabilities that need further work. This task is daunting, but will not only help retain valuable historical vulnerability information, but will also allow OSVDB to generate meaningful statistics for past and current years.
We have had a great year, and are looking forward to another one! We are of course still seeking assistance to help keep OSVDB successful–the project has many ideas in need of financial and volunteer support to implement. For more information on supporting OSVDB through volunteering or sponsorship, please contact email@example.com.
In the context of advisories, it’s simple, to help track documents and avoid confusion. Much the same reason a vulnerability database assigns a unique number to an issue. If there is confusion when discussing a vulnerability, you reference the unique ID and ideally, confusion goes away. That said, why does Hewlett-Packard feel the need to assign multiple tracking IDs to a single document/advisory?
HP-UX running WBEM Services Denial of Service (DoS) http://archives.neohapsis.com/archives/bugtraq/2005-12/0231.html
So this is “SSRT051026 rev. 1”, “Document ID: c00582373”, and HPSBMA02088. Three drastically different tracking numbers for the same document. Fortunately, all three were referenced in the same place this time, but still.. why must vendors do this?