The Upside to the Provenance Problem
Posted by jericho
As mentioned before, Christey of CVE mentions an ongoing problem in the vulnerability world is that of “provenance”, meaning ”where the hell did that come from?!” Vulnerability Databases (VDB’s) like CVE and OSVDB are big on provenance. We want to know exactly where the information came from and include it in our entry. Other VDBs like Secunia or SecurityFocus’ BID are bad about it. That is to be expected though, we’re talking free/open vs commercial/closed. BID/Secunia gain some value by appearing to be magical when it comes to finding vulnerability information.
For anal retentive freaks, the provenance problem does have one upside. For years now, OSVDB has been agressive in digging up vulnerability information, regardless of age or severity. This typically means spending hours upon hours of reading changelogs, which usually are not the most stimulating reading one can find, and more often than not lack any form of clarity or simplicity. This also means relying on a bit of guesswork at times, as changelog entries tend to be short and sweet, leaving a lot to the imagination. One such example is the recently published Empire Server Unspecified Vulnerabilities from Secunia. As always, unspecified and no reference as to where the vulnerability information came from means looking at the vendor site, bug tracking systems, news archives, changelogs and more. An hour after digging, I still can’t find where exactly Secunia got ”Some vulnerabilities with unknown impacts have been reported in Empire Server. The vulnerabilities are caused due to unspecified errors in the game server.” One of the OSVDB manglers (mdodge) was able to track down where this information came from while I was knee deep in changelog.
Despite that, OSVDB will soon have as many as 12 more entries for the Empire server from other Changelog entries, and I’m not even 10% done reading. I’m conflicted here.. part of me is sad, because the only other previous entry OSVDB has for this is an old entry dating back to 1981 and nothing since. That is depressing in the world of VDBs, and a discredit to what we do. Consider the entries in various VDBs: CVE 0, ISS 0, ST 0, BID 0, Secunia 1, OSVDB 2. Yet the changelog for the 4.x branch suggests over a dozen vulnerabilities?
The other part of me is happy as this is one more product that will be better represented in a VDB as far as security goes. People want better vulnerability trending, a more accuracte vulnerability history and a better idea of a product’s security. That won’t happen without a more complete picture of the vulnerabilities in a given product.
What is sad is that people generate statistics based on the information in various VDBs. VDBs have a long way to go before they can be used for this purpose.
Take your example of…
CVE 0, ISS 0, ST 0, BID 0, Secunia 1, OSVDB 2
This means that the public will think that Empire Server is more secure than , since there are no vulnerability entries for Empire Server in the other VDBs.
Meanwhile, you just pointed out that there are over a dozen to be made and this product could actually be far less secure than !
This happens all the time. Another great example is when one BSD OS will report a vulnerability and the others will pass on it. Take Dragonfly BSD, for instance. No vulnerabilities! This product is by far the most secure of any OS. Well, of course not, this OS is a fork from FreeBSD and comes with the same garden variety vulnerabilities that FreeBSD has now and has had. It’s all a matter of flying under the radar of the VDBs. As long as Dragonfly keeps its mouth shut and doesn’t give the VDBs any reason to create an entry, there will be no entries.