Determining what constitutes a vulnerability is a complex issue that is challenging for projects that specialize in cataloging security vulnerabilities. The
definition of a vulnerability is varied, and the security industry has yet to truly standardize on vulnerability terminology. This issue was recognized some time ago by the MITRE Corporation's CVE project, which has relevant information posted on its
web site.
When trying to determine if a vulnerability deserves an entry in OSVDB, there are many things to be considered. To aid in this process, we attempt to determine answers to the following three questions:
- Is it really a vulnerability?
- What/where is the root cause of the vulnerability?
- How many entries should be created?
Is it really a vulnerability?
With so many vulnerability reports released every day, all available information is reviewed before an entry can be added to OSVDB. One of the many goals of OSVDB is to include all entries posted to public mailing lists, even if information is suspect or is later proven to be false. Using vulnerability classifications, OSVDB will attempt to distinguish real and fake vulnerabilities. To achieve this goal, OSVDB uses "Myth/Fake", "Concern", and "Best Practice" classifications to more accurately qualify a vulnerability. The project also maintains a "Verified" classification, which indicates that the vulnerability has been confirmed to exist by the vendor or by an OSVDB volunteer.
What/where is the root cause of the vulnerability?
OSVDB is a project to collect and document vulnerabilities. The project assigns new entries based on what and where the vulnerability is, not based on the products that are affected.
The biggest cause of confusion has been vulnerabilities in libraries (i.e., libc, libneon, etc.). In such a case, OSVDB assigns a single entry for the vulnerable software itself, which would be the library. So if libc is vulnerable to an overflow, the OSVDB entry gets created for that problem. The fact that wu-ftpd and dozens of other programs rely on libc and can be exploited as a result of this flaw does not mean they each get an entry. In this example, the libc entry would cover what versions of libc itself were vulnerable, and which versions fix the vulnerability. If other products rely on the library, they may be mentioned in the technical description, but not in the product information section.
However, if a vulnerability is found in a shared library that is compiled into a program one time and not updated, or the program authors make their own changes to the library, the entry should be created for that product. This entry's product information would list the vulnerable product, not the library it used.
How many entries should be created?
Many times a vulnerability must be broken into many entries. Often a security company or vendor will release multiple issues, in one product, in a single advisory. The goal of the database is to assign a unique OSVDB ID to each unique vulnerability. The key is to look at the issues and to determine if they are dependent upon each other, or if they can happen independently. For example, if there are 3 cross site scripting vulnerabilities in a product that can only be found with all of the others, then all 3 issues should be grouped into one OSVDB ID. However, if it is possible to find each of the issues by themselves, then each should have its own OSVDB ID. The main reason for this is that when reports are generated, OSVDB needs to be able to clearly identify unique issues that are found. OSVDB does not want to say we found one issue, but the OSVDB ID generically represents four other vulnerabilities. The general rule of thumb is that we create an entry for each vulnerable script, not variable.
OSVDB accounts are grouped into four main roles within the project:
- Moderator - This role handles a variety of tasks, including general database content maintenance, reviews and approves database entries, answers questions related to the database (from volunteers and the public), and more. In the new OSVDB 2.0 system the functions that were previously handled by a Newdatamangler have been merged into the Moderator role. This includes being responsible for creating new vulnerability entries after verifying they do not already exist in OSVDB, provide initial external references to help volunteers start working on an entry, update new information (typically external references) to other recently-new entries, and ensure the databases historical information is complete.
- User - User, are accounts that are created to use OSVDB services including the watch list and download the database. User accounts also have the ability to provide updates for vulnerabilities.
- Datamanglers - Datamanglers, (often simply referred to as "manglers"), are users that have contributed to the content of the database and are responsible for updating vulnerability entries to ensure accurate and complete information. This role is the core reason why OSVDB's database will be successful.
- Developers - OSVDB has a group of developers that make everything possible. They work as a team and help make projects goals a reality , and keep the technical aspects of the project up and running smoothly.
OSVDB 2.0 documentation will be published soon!
External references are provided to give additional information for a vulnerability. These references also serve to cross reference OSVDB IDs with other vulnerability databases or key resources. OSVDB makes every attempt to add all references available to each entry in the database. The project intends to fulfill the recognized community requirements for an open, centralized resource for security information.
The following guide sets standards for external references and provide additional information. These descriptions include the base URL to find more information, as well as what the OSVDB mangler will input into the particular field. Many of these are designed to take a number or reference, and the backend will build the URL/link automatically
Qualities that typically lead to a product obtaining a unique External Reference are as follows:
- Partnership with OSVDB
- Considerable amount of references to OSVDB
- Other widely used projects/databases that provide similar services
- Direct link uses ID which can be easily mapped to a full URL
- Generic category that appears in over 50% of OSVDB entries
- Large vendor with considerable market share (Microsoft, etc.)
- Security tool that has cross-references with OSVDB
For more information on external references, please see the
External Reference documentation.
OSVDB wants to be a central place to credit researchers for their discoveries and work. If available, OSVDB enters the name and e-mail address of the person(s) who discovered the vulnerability.
If the software maker/vendor released an advisory, we do not list them as the creditee since they typically do not give credit to the actual person who found the vulnerability. If the advisory specifically says the bug was discovered by the internal vendor engineers, then OSVDB credits the vendor.
OSVDB uses a vendor's full name in the database. This means that a vendor will be listed as "Cisco Systems, Inc." instead of "Cisco", for example. Project volunteers visit the vendor webpage and use the information on the main page or copyright notice. The only time the project changes an official name is to drop "the", so that"The Vendor Group, Inc." would be listed as "Vendor Group, Inc."
The project makes ever attempt to include every relevant version that applies. The only time wildcards are used is when we are 100% sure that the entry will be accurate. If the current version of a product is 1.3, we will NOT use 1.x to label the vulnerable versions, as subsequent releases will likely not be vulnerable.
External texts are the main information source in each OSVDB entry, and help users understand the issue as well as how to test and correct.OSVDB has templates to address consistency issues in the database, since all volunteers have very unique and different technical writing style. This also ensures that the same facts were being included from entry to entry.
- Vulnerability Description - A high level description that a system administrator would want to read and understand. In addition, it is intended to help users of OSVDB generate reports on vulnerabilities.
- Technical Description - Used to provide any relevant technical information about the vulnerability. This field is typically used to include new information, clear up something that may not have been obvious, or provide a concise summary of details. This field is also meant to include the very specific technical details that most system administrator may not want to read.
- Manual Testing Notes - Notes on how to test for a vulnerability. This may be details on how to check the presence of files, configuration options, a test URL, log output or more. The projects tries to ensure that any manual testing notes do nothing malicious, manipulate no files, or put the system at risk--however it is not guaranteed that the test will not harm the target.
- Solution Description - Specific information about an available fix, but will not contain an actual URL (that should be included in the external references section). OSVDB does not recommend solutions such as "use another product" or "use a firewall to filter malicious traffic". The solution is meant to be relevant to the product itself or the operating system it runs on.
