Version

A basic requirement of vulnerability management is accuracy. Correct assignments of affected products and versions are important for confidence. The moderation team is eager to provide the best level of accuracy by searching and comparing all available sources for vulnerability intelligence.

The quality of this raw data is often not very good or even contradicting. Especially when it comes to information about which version of a product is affected. It is not unusual that different sources list different versions as affected. There are also different methodologies to indicate affected versions:

ApproachExampleSymbolizedRemark
List2.4.0, 2.4.1, 2.4.2, 2.4.32.4.0, 2.4.1, 2.4.2, 2.4.3preferred
Range2.4.0 to 2.4.32.4.0-2.4.3alternative
Wildcard2.4.x2.4.*alternative (limited)
Upper Limit (including)up to 2.4.3<=2.4.3fallback
Upper Limit (excluding)prior 2.4.4<2.4.4fallback
Lower Limit (including)2.4.0 and newer2.4.0<=not useful
Lower Limit (excluding)newer than 2.3.92.3.9<not useful
Sub-Ranges2.3-42.3.x, 2.4.xto avoid

VulDB is preferring a list whenever the affected versions are conclusive. This provides the highest data quality and confidence. If raw data is inaccurate or incomplete we are using an upper limit definition if the upper limit of the affected version is known (including) or if the first not affected version is known (excluding).

The problem with range definitions like these is, that the searching within the database becomes hard to do. If an entry notes that up to 8.1 is affected, a search for XP might not match within the database.

To prevent such false-negatives we are expanding versions based on our experience and machine-learning of approved entries with similar structure. Therefore, an entry with up to 2.4.3 would be expanded as 2.4.0/2.4.1/2.4.2/2.4.3.

If a product is not flagged as do not expand in our database, we will always do this for the minor version (here 2.4.x). In this case every minor version is handled in a dedicated way. This is a requirement for products which have independent minor branches (e.g. WordPress, Linux Kernel). In this case to include 2.3.x in the expanding the entry would have to have the definition of up to 2.3.3/2.4.3. Some products are flagged that an expading is allowed for major versions like 2.x.x.

Such an expanding is not that hard if the version numbers are incremented. But some projects have word-based version numbers (e.g. Microsoft Windows), non-linear increments of versions (e.g. Google Chrome), or in-between releases (e.g. betas, release candindates). To handle the expanding of these we enrich our database with an overview of versions. In the case of Microsoft Windows the database holds the version vector [ 'XP', 'Vista', '7', '8', '8.1', '10' ]. If an entry claims that all products are affected up to 10, then all earlier versions are listed too as XP/Vista/7/8/8.1/10.

Nevertheless, we do not recommend using version data in fully-automated processing in business-critical systems. The data quality and accuracy might not be high enough to do so.

Interested in the pricing of exploits?

See the underground prices here!