OSVDB Mangler Walkthrough
[Note: This document is out of date.]
You will need to create an account on OSVDB. (http://osvdb.org/)
Click on the Account link on the left hand side menu, and then click Sign-Up or visit https://osvdb.org/account/signup
Please complete the information requested, complete the CAPTCHA and click sign up! You will be sent an email with a link to confirm the account.
Once you are logged in you will see additional menu options. Before you get mangling it is important that you are brought up to speed on what the expectations are for each vulnerability. Before you even think about grabbing an entry and sinking your teeth in, take a couple minutes and read the information provided or ask for some assistance. This will save you considerable time and significantly enhance your contribution to the project.
My Portal - This link provides a quick dashboard for your account and provides some quick links to resources you may want to visit:
Who's Online - Provides a quick look at who is online working on OSVDB.
This is the e-mail address that will be used for e-mail notifications (mangle accept/reject) and listed on the mangler back end page.
Results Per Page
Enter in the number of results you would like displayed per page for search results and vulnerability browsing.
When this feature is active, you will be sent emails when the status of a vulnerability that you have mangled has been either approved or declined.
My Watch List - This feature lets you setup OSVDB to help you watch vulnerabilities in the database or vendor security mailing lists.
The Vendor/Product Watch List
This Watch List will alert you to vulnerabilities for specific products that you subscribe to. Alerts are generated when a vulnerability is updated to include the product and vendor information. Soon, we may introduce a feature that will enable alerting as soon as the vulnerability is processed through our systems.
To add a product to your Watch List, visit the vendor section of the website, find the vendor, then find the product and click the button next to it. To add an entire Vendor, or to add more than 10 products to your watch list, you must purchase a subscription. If you work on the project just ask a moderator and we will provide this to you without any issues.
The Mailing List Aggregation Watch List
OSVDB allows you to subscribe to roughly 20 vendor advisory mailing lists. The advisory mailings are sent to OSVDB, we process them, and forward them on to you. That way, rather than managing 20 individual advisory subscriptions, you only need to manage one through OSVDB.
Start Mangling - Now that all the settings have been configured, let's get our first vulnerability in our queue. There are two ways to do this based on your preference:
To do this, from the home screen, click on "Update OSVDB" link. Next click "Update Random Vulnerability". This will put the next new vulnerability that needs to be mangled in your queue.
If you would like to update a specific type of vulnerability, whether it is a certain vendor or type of vulnerability, this can also be accomplished. Any vulnerability that you view you can click "Edit Vulnerability" on the top right underneath the vulnerability title that is being displayed. The easiest way to find the vulnerability you would like to edit is by searching here: http://osvdb.org/search/advsearch
Remember, the goal of OSVDB is to create a concise, accurate and original entry. Once you select a vulnerability to edit, you can see the major sections of each vulnerability which are the following:
General - Core information about the vulnerability, including dates and text fields.
Classifications - Attribution about the vulnerability can be added.
Testing - Detailed testing notes and web checks can be added.
References - Links and cross-references for the vulnerability.
Credits - Information about the researcher who disclosed the vulnerability.
Internal Notes - Notes about the vulnerability or mangling that are not public.
As you look through each of the sections you will see a question mark next to each field. If you click the question mark it will display information that will help you better understand what is expected for that field. It is also important to know that you don't have to fill out every field before you submit. If you want to just update creditee information, dates or classifications you can do that! Any updates that we can get help improve the quality of the data!
The number one rule of mangling: don't assume that any information in an entry is auto-magically correct! The success and accuracy of OSVDB comes from the idea that many sets of eyes will provide the accuracy we want. If everyone assumes that every field they don't edit is already accurate, we're going to have a lot of bad information. Moderators do their best to start the entry off with an accurate title, some external references, and any notes about special mangling if needed.
As a mangler, you are not expected to do extensive research or manually test the current or old versions of the software. The external references should fully validate having the vulnerability entry in our database. If you are interested in digging into the issue more, you are certainly welcome to and we'd love detailed notes. Finding additional vulnerabilities or more details to the ones we know about are great, but not required.
The best way to get started is to look over the existing information that is currently in the entry. Start by looking at a couple of the existing external references. These are added by either the Moderator or the import process. If you would like to find more references you can search on your own or use the ADD CVE REFS function to import more from CVE. It is important that you identify the original disclosure link, often a mail list post or exploit site like milw0rm, as it will contain the most information.
You will see in the top far right the Internal Notes links. If there is an asterisk next to the link, that means there is a note included that might be worth reading before you begin mangling. These will sometimes be used to put moderator notes related to how the entry should be mangled or what additional information should be noted..
Often times a Bugtraq post will be convoluted or have mistakes. The moderators will do their best to make it very clear what this entry pertains to. If the title is for a specific script and vulnerability (such as "jericho.php XSS"), do not mangle it for more than that! There should be additional entries in the database to cover the other issues. If you feel the vulnerability has not been split out correctly, contact a moderator.
On the General tab, you can update as many fields as you want including dates, keywords or other text fields, and hit 'Update' once.
There are several date fields that we look to fill out. If the information is not available for a specific field, leave it 1970-01-01.
Disclosure Date: The most important is the date the vulnerability was disclosed, and should come from the original advisory or mail list post. The disclosure date is set during the vulnerability import procedure, but we benefit by having the mangler verify it. It is very rare that we will have external references and no information about the public disclosure. In a few cases, we may only know the month and year though. In such a case, use that and list the day as 01 (e.g., 2009-01-01).
Discovery Date: In some cases, the person may include when they actually discovered the vulnerability (before disclosing it to the public), especially if they include a time line of the vulnerability reporting process.
Exploit Publish Date: If the original source included exploit information, fill out this field as well. Even if traditional exploit code wasn't published, if enough information was included to easily exploit the vulnerability then include the date. Note that a SQLi disclosure showing "/script.php?parameter=[SQL]" does not qualify as exploit published; SQL injection is considerably more complex than [XSS] or [RFI].
Solution Date: The date that a solution was provided by the vendor.
Vendor Informed Date: The date the researcher disclosed the vulnerability to the vendor. This is typically evidence when a time line is included.
Vendor Ack Date: The date the vendor responded to the researcher after initial disclosure. This is typically evidence when a time line is included.
3rd Party Solution Date: The date that a solution was provided by anyone other than a vendor. This should be for a real solution, not a workaround that can significantly impact operations (e.g., use a firewall to restrict access to the server).
This field is designed to be a brief description that incorporates all relevant information. This is the type of field you may see as output from a security product such as the Nikto scanner. In general, think of the OSVDB title with version information injected into it. Often times it is best to copy the title and add version information.
As with the product information, the version notation must be accurate! We can't use "4.x" if only 4.1 - 4.4 are vulnerable. Unlike product information, you can use any short hand notation or wildcards.
In general, the search engine will find any words in the vulnerability entry, so you don't need to include every possible word from the description. This field is ideal for information related to an entry that doesn't appear anywhere else in the entry.
Some good uses of this field:
These words or phrases should be a comma separated list. Once you have entered them, hit the modify button to update your entry.
 Some of the manglers have started adding related ports in this field in the format of "TCP Port 123" or "UDP Port 923". The idea is this will provide search functionality so that a user can find all vulnerabilities associated with a given port. We are currently considering adding a dedicated field for this. Until that happens, you should use the Keyword field for port association.
This part of each vulnerability was proving to be the hardest; so we developed templates to address multiple issues. Remember that each vulnerability must have a Vulnerability Description and a Solution Description at the very least.
The best way to create these is to use the template function at the bottom of each field. Click the pull down menu next to "Template" and choose what you are trying to add. For example, if you are trying to add a Vulnerability Description for a Denial Of Service attack: you would select from the template pull down menu, "Vulnerability Description: Denial Of Service". This will copy the template to the text box above where you can edit it and then add it to the entry. The goal of having templates is not to be restrictive but to make an attempt to standardize the format and wording of the database. It is important to note that even with defined templates, Data Manglers are empowered to reword and rewrite external texts as they see fit. After it is reworded, click "Save Changes" at the bottom.
External texts should not include HTML links at all. If you need to reference a web site/page, include it in the external references instead. Text would then include "Apply the vendor patch.." or some other way to reference the link already provided. We assume that OSVDB users will know to read the links above the text.
The Vulnerability Description should not include or reference version numbers. This is better handled in the Product Information and would be repetitive. Only the short description should include versions.
The Technical Description should be used to provide any relevant technical information about the vulnerability. This field will be completed at your discretion. Obviously the original post or advisory will contain more information than we provide and we don't want to cut/paste or re-invent the wheel. This field is ideal to include new information, clear up something that may not have been clear, or provide a concise summary of details. This is also a great spot to list any caveats for the vulnerability, such as certain configuration options being required.
The Solution Description should always follow a template. We do not recommend such things as "use another product", "edit the source code" or "use a firewall to filter malicious traffic" (like Secunia does). The solution should be relevant to the product itself or the operating system it runs on.
Templates. Templates. TEMPLATES. Redundant, yes, extremely important, yes! It is critical you use the provided templates any chance you can. If you don't like the way they are worded, alter them as needed to explain the information and feel free to contact the moderators with suggestions.
One of the biggest problems with using templates is sticking to them too closely. They are templates.. meaning guidelines. Don't fill in the blanks and submit, as this will often make for clumsy entries that do not read well. Changing verbiage to match is important!
The Internal Notes field is for including information about the vulnerability that will not be seen by the public. Including snippets of changelogs or mail from a vendor clearing up a question should be put in this field if applicable. If you contact a vendor for more information, please make mention of who you contacted, the date and the subject.
When determining the classification, keep in mind you are classifying what the vulnerability itself entails. Don't flag extra categories if you think they are indirectly related; stick to the minimum required to accurately classify.
Physical Access Required - Physical access to the device or server is required to exploit the vulnerability.
Local Access Required - Local access is required to exploit this vulnerability (e.g., unix shell, windows user).
Remote / Network Access - This vulnerability can be exploited over a wired network (e.g., LAN, WAN, Internet).
Local / Remote - This vulnerability can be exploited with local or remote (network) access.
Context Dependent - To exploit this vulnerability, victim interaction is required (e.g., clicking a link, loading a file).
Dial-up Access Required - A modem dial-up is required to exploit this vulnerability.
Wireless Vector - This vulnerability involves a wireless vector for exploitation.
Location Unknown - The attack vector was not disclosed.
Authentication Management - A vulnerability that attacks or bypasses an authentication mechanism. Exception: If an attack uses SQL injection to bypass auth or add an administrative account, the attack itself is not authentication based, unless that is the only thing that can be done with the attack.
Cryptographic - A vulnerability that attacks a cryptographic implementation (e.g., compromising an algorithm), relies on the presence of weak cryptography (e.g., password protection via XOR) or relies on the lack of cryptography (passwords stored in plaintext, information transmitted in cleartext).
Denial of Service - A vulnerability that results in a loss of service, functionality or capability. This includes making a service unresponsive, consuming resources (e.g., CPU, memory) or forcing a reboot.
Information Disclosure - A vulnerability that results in the disclosure of information that may be sensitive (e.g., passwords, credit info) or useful in conducting additional more focused attacks (e.g., usernames, installation path).
Infrastructure - A vulnerability that attacks an infrastructure device, such as a large router, firewall or another device supporting BGP. This does not apply to SOHO routers.
Input Manipulation - A vulnerability that is exploited by sending manipulated and unexpected data to a service or process. This includes all types of overflows, memory corruption, XSS, SQLi, RFI, traversals and more.
Misconfiguration - A vulnerability that exploits a misconfiguration in a system or software. Misconfigurations can be as shipped by a vendor (e.g., version 3.3 accidentally shipped with insecure options), or by administrators who would reasonably configure software incorrectly (e.g., common sense or product documentation would lead to it).
Race Condition - A vulnerability that can only be exploited during a specific 'window of attack'. Typically a race between two actions where the first makes a system vulnerable, and the second removes the condition for exploit. This is frequently seen in temporary file handling, but may apply to a wide variety of attacks.
Other - A vulnerability that cannot be defined by any other Attack Type classification.
Attack Type Unknown - The attack type for this vulnerability is not known.
This is by far the biggest cause of problems to date. The impact of a vulnerability should be listed based on what the vulnerability itself affects. More often than not, people are flagging all overflows with all three impacts, and this is somewhat understandable. If I can exploit a remote buffer overflow and gain root, I could then read files (confidentiality), delete files (availability) and edit files (integrity). However we can't flag a classification based on what an attacker might do. With that in mind, if an overflow crashes a service it would clearly be an issue of availability. If the overflow gave increased access such as root or administrator privs, it would fall under integrity. In some cases, the overflow may allow both classifications and should be noted as such (e.g., lot of garbage sent will crash, while shell code will give privs).
Loss Of Confidentiality - Assurance that data is protected and not disclosed to unauthorized party.
Examples: password disclosures, server information, environment variables, confirmation of file existance, path dislcosure, file content access, some SQL injection.
Loss Of Integrity - Assurance that data is unaltered by unauthorized persons and authorization has not been exceeded.
Examples: XSS, arbitrary command execution, most overflows, most format strings, SQL injection, unauthorized file modification/deletion/creation, remote file inclusion, etc.
Loss Availability - Assurance of timely and reliable access to data.
Examples: any DoS attack of any kind, unauthorized file deletion, etc. anything that can cause the availability of a service or information to be impacted.
Exploit Public - A working exploit is publicly available.
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 Rumored - An exploit is rumored to exist, but cannot be confirmed.
Exploit Unknown - The status of a working exploit is unknown.
Exploit Wormified - An exploit has been crafted to spread via 'worm' or 'virus'.
Cross site scripting (XSS) attacks are trivial to exploit 99% of the time, so flagging them as exploit available is fine. SQL Injection attacks however, can be very tricky to exploit. If the researcher puts something like "/script.php?variable='SQLINJECT", that is not enough to flag exploit available.
OSVDB Verified - The vulnerability was verified by the OSVDB volunteer.
Vendor Verified - The vendor has verified this vulnerability.
Vendor Disputed - The vendor has disputed the disclosure, claiming it is inaccurate or not a risk.
Third-party Verified - A third-party (e.g., not the researcher or vendor) has verified the vulnerability report.
Third-party Disputed - A third-party (e.g., not the researcher or vendor) has disputed the vulnerability report.
Coordinated Disclosure - The researcher and vendor coordinated disclosure so that vulnerability details were released in conjunction with a solution.
Uncoordinated Disclosure - The researcher disclosed vulnerability details without waiting for a vendor to provide a solution.
Discovered in the Wild - The vulnerability was originally discovered "in the wild", being used to compromise systems before disclosure through regular means.
Please pay special attention to the OSVDB column. These are classifications that are fairly unique to OSVDB!
Authentication Required - This vulnerability can only be exploited after successful authentication.
Vuln Dependent - This vulnerability can only be exploited with the presence of a second specific vulnerability.
Web Related - A vulnerability in an HTTP(S) related product.
Concern - This issue may not be a true vulnerability, but is of concern as it could lead to more severe vulnerabilities, or more easily result in the compromise of a system.
Myth / Fake - After disclosure, it was demonstrated that the vulnerability report was incorrect. (This will usually be flagged by a moderator already.)
Security Software - A vulnerability in software designed to enhance security or offer protection (e.g., firewalls, anti-virus, etc)
"OSVDB Verified" should only be checked if you (the mangler) personally verify the vulnerability exists (meaning you download the software and test). If you personally validate the vulnerability, please indicate that in the Internal Notes along with the date.
The Testing notes should be included if a vulnerability can be tested for. This may be details on how to check the presence of files, configuration options, a test URL, log output or more. Ensure that any manual testing notes do nothing malicious, manipulate no files, or put the system at risk. When providing examples, avoid using "example.com" or other arbitrary domains. To denote the system being tested/attacked use [target], and to denote the attackers system, use [attacker]. Do not include hundreds of lines of C code! Link to an exploit URL instead.
This can be tricky for a new data mangler to understand and deal with correctly. The first thing you should do is make sure you understand the versions affected by the vulnerability.
Look to see if the product combination that you are looking for exists in the database. This is done by entering the vendor name and giving the system a second to show matches. Input the product name and wait a second for the system to show matches. If there are affected versions, they will be presented as checkboxes. If the product is not in the system, an input box will allow you to add comma separated versions (e.g., 1.1,1.2,1.3,2.0). BE CAREFUL HERE as entries you type by hand are added as new entries if they aren't found. This means typos are added and they are a pain in the ass to deal with by the moderators at a later date! Make sure you don't have a trailing space at the end of one of your fields, or it will create a new one.
As painful as it may be, please include every relevant version that applies. The only time we use wildcards is when we are 100% sure that the entry will be accurate. If the current version of a product is 1.3, we can NOT use 1.x to label the vulnerable versions, as subsequent releases will likely not be vulnerable.
Some products are small packages and may present a problem related to the vendor. If John Doe writes a small freeware pacakage, there may not be a company associated with the product. In this case, you may choose to use the author's name (ie: John Doe - ProductName - 1.0), or the website name. If there is no name or vendor to associate, you should then use the product name for both vendor and product.
A general rule for adding products is that if it is less than 10 or so entries, refrain from using any sort of wildcard. If there are more than 10 listings w/o using wildcards, then use them conservatively so as not to flood the page with version numbers. In the case of multiple beta versions or 'pre' releases, you may use wildcards at any time as long as the designation is accurate.
Newly discovered vulnerabilities can be a little tricky. Despite the desire of listing 'all versions' vulnerable, we need to list only the current versions known to be affected. If a patch is released days after the vuln is published and our entry says 'all versions', it will quickly contain inaccurate information.
When adding a vendor name, please use their full copyrighted name! This means adding "Cisco Systems, Inc." instead of "Cisco". If you have any question as to the name they use, check the bottom of the main vendor home page and the copyright notice usually shows it. The only time you should change their official name is to drop "the" .. so "The SulloSoft Group, Inc." would be "SulloSoft Group, Inc." Check the input boxes first, as it is likely we already have the vendor in the database!
Reminder: You can not use any notation such as <, >, <=, "before", "less than", etc.
There are a few cases where we've seen a product that contains a vulnerability, but the product is not distributed in a typical .tar package with version number. LiveJournal (software, not the web site) and Mozilla Bonsai are two such examples. Each one is distributed only via CVS checkout, so you can't easily list "1.3" or "5.2" as vulnerable. In such a case, you can list "Unknown or Unspecified" for the version, then explain the situation in the technical description:
Bonsai is not distributed as a versioned package. To determine if you are vulnerable to this issue, verify the date you checked out a copy of the package. If the check out was done before 2002-08-28, you are likely vulnerable.
In this case, you may also opt to use a date for version number in the product info.
The creditee is who discovered and disclosed the vulnerability. This may be one person or a small group. We add each person individually in the case of multiple people.
When you input the name, use the person's full legal name if available, and their nickname / handle if not. Once you type it in, give the system a second to show you matches. If a match exists, adding it should auto-fill in additional fields for you. For 'Country', only list it if the information is available; do not base this on the location of the company the creditee works for.
Some last minute "gotchas" to watch out for!
There is no standard for referring to the bad guy. Use your discretion in figuring out if "malicious user" or "attacker" or something else is the best. Typically, "user" refers to someone on the inside of an organization while "attacker" is commonly accepted to mean a remote bad person.
Instead of using "vulnerability" frequently (it IS a vulnerability database afterall!), use "flaw", "issue" or similar words where appropriate. People don't code vulnerabilities on purpose.. they code buggy/flawed software that leads to a vulnerability.
What is a vulnerability?
One thing to watch for is a new OSVDB ID based on an advisory or post that contains multiple vulnerabilities. Often times a security company or vendor will release multiple issues in a single advisory. The goal of the database is to assign a unique ID# to each vulnerability in the real world. This will take a lot of discretion and personal judgement to do in a reasonable fashion, as every single little function or variable shouldn't have it's own ID# necessarily. Most of the time, this will not be an issue as the NewDataManglers will split the vunerability into the correct entries before you mangle. In the case you get an entry that needs splitting, ask a moderator first. If they end up splitting for you, it is still good that you understand our process; let's look at two examples that may give you an idea and some guidance:
Original Bugtraq Post for "RNN Guestbook Multiple Vulns":
SecurityFocus / BID filed this as a single vuln:
ISS X-Force filed this as 4 vulnerabilities:
OSVDB assigned the same 4 ISS did, and a 5th that they apparently missed or didn't consider a vulnerability:
In this case, there were five distinct issues present in the Guestbook script and are easier to reference when divided out.
The next example is an OpenBSD Denial of Service attack--OpenBSD Local semctl and semop DoS:
Although there are two vulnerable functions, they are vulnerable in the same versions to the same style of attack, so they are classified in a single entry. In short, don't be afraid to take a newly assigned vulnerability and ask a moderator if it should be split into multiples if you think that is best. We encourage manglers to help us by verifying moderator activity!
While this should be taken care of by moderators during the vulnerability import process, we encourage manglers to understand our standards. For advisories that include a dozen SQL injections or cross site scripting bugs, use your discretion. The general rule of thumb is we create an entry for each vulnerable script, not variable. For example:
Jakesoft sullo.php jericho Parameter XSS
Jakesoft jericho.php sullo Parameter XSS
Jakesoft fbr.php weet Parameter XSS
Jakesoft sullo.php jericho Parameter SQL Injection
Jakesoft sullo.php weet Parameter SQL Injection
Jakesoft sullo.php nikto Parameter SQL Injection
In this case, the second would be one entry:
Jakesoft sullo.php Multiple Parameter SQL Injection
The biggest case of confusion to date has been vulnerabilities in libraries such as libc, libneon, etc. As of June 4, 2004, the policy is that we assign an entry for the vulnerable software itself. If we find out libc is vulnerable to a buffer overflow, the entry gets mangled as such. The fact that wu-ftpd and dozens of other programs rely on libc and may be exploited as a result of the vulnerability does not mean they too get entries. In such a case, the entry would cover what versions of libc were vulnerable and which fixes said vulnerability. If other products rely on the library, they should be added to the product information!
On the other hand, 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 mangled for that product. Product information would list the vulnerable product, not the library it used.
If you aren't burying your computer in a ditch while cursing OSVDB by now, you are ready to mangle!