The argument that Vulnerability Databases (VDBs) are evil because they provide the bad guys all of the information on how to hack has gone on for quite some time. Of course, this debate crosses over into the Full Disclosure argument, which asks the question, should the information be public at all? But for VDBs, the real question should not be about whether to provide information on vulnerabilities, but how specific the information cataloged should be?
Some believe that providing exploits or tools to make it easier to exploit a vulnerability is where it crosses the line on providing too much information. While there may be a few valid points on the topic, the real issue, in my opinion, is when resources provide vulnerability information in the context of a specific site/domain.
VDBs are not the only resource that may have site specific vulnerability information. Many search engines such as Google/Yahoo have come under fire as being a collection of security information to assist attackers. In fact, it could be argued that the search engines pose greater security disclosure problems than a VDB, since a search engine takes an attacker immediately to a vulnerable website. There is even a whole site (and following) centered around using Google to quickly find specific vulnerable software on web sites.
OSVDB has a policy that we do not catalog site specific vulnerabilities, and we make all efforts possible to avoid these entries being added to the database. In fact, quite a few VDBs follow this same practice. However, some VDBs will include sites specific vulnerabilities only for high profile websites. For example:
XSS vulnerabilities in Google.com: http://www.watchfire.com/securityzone/advisories/12-21-05.aspx
Google GMail ‘CheckAvailability’ Script May Disclose User Information to Remote Users: http://www.securitytracker.com/alerts/2004/Jul/1010647.html
Yahoo! Mail ‘order’ and ‘sort’ Field Input Validation Flaw Permits Cross-Site Scripting Attacks: http://www.securitytracker.com/alerts/2004/Mar/1009352.html
It is important to note that certain advisories make it very hard to determine if the issue is in a product or on a website. Recently, we have seen what appears to be more site specific issues being released by researchers. For example:
SpearTek Search Field Handling Cross Site Scripting Vulnerability: http://www.frsirt.com/english/advisories/2005/3052
There appears to be quite a few advisories released by r0t that may fall into the site specific category. If you look on r0t’s site, anything that says there is a XSS vulnerabillity in the “Search Module” may very well be a vulnerability in the company website, not in the product–even though he lists version numbers in the advisory.
Considering VDBs such as OSVDB do not have the resources to verify all advisories, we must rely on the information provided, and in some cases site specific vulnerabilities make it into VDBs by accident. In fact, dozens of entries in OSVDB currently have internal flags on them as we try to determine if they are site specific.
Providing a company website or an online service that has a security issue is not something that OSVDB believes to be appropriate, even though many contributors personally find it extremely interesting, and believe it is valuable. Many organizations that rely on online services may find great value in knowing about an issue with their online email provider. The fact that many businesses use sites like Google, Gmail, or Yahoo heavily suggests that vulnerabilities in the services are just as dangerous as vulnerabilities in the software deployed on their own network.
It may make OSVDB look incomplete compared to VDBs that include site specific vulnerabilities, but we are willing to accept that risk. The OSVDB project aims to provide useful information to help improve the level of security for the community, and site specific vulnerability do not fall in that category currently.