I am all about the pedantic nature of running a vulnerability database (VDB). It’s the backbone of running one well as “simply aggregating vulnerability information” is anything but simple. I’ve been outspoken on the issue of perceived simplicity for at least two decades and brought it up in various presentations and blogs. This blog is not new in that I have very briefly covered it in a prior blog and discussed it at conferences and it has come up in various conversations over the years. But I wanted to do a more definitive blog with a few examples, for the record.
Most recently it came up at the end of last year in the Extended Vulnerability Community (EVC) discord server. Josh Bressers, who disclaimed he would not die on this hill, said “I would mark these as <= rather than a single version as I think that’s the vastly more common situation“. This comment was made in the context of tracking affected versions for a given vulnerability. I wrote documentation around this back in 2011 / 2012 for VulnDB to help our customers better understand how we approached it, and why.
In response to Bressers, I said I disagreed because assuming all prior versions are affected is not always true. To expand on that we need to consider several factors. First, some developers and organizations will make the decision to stay on an older version for a variety of reasons. If they are then presented with a vulnerability that allegedly impacts them, it may force their hand to upgrade. In reality they may not have been vulnerable to begin with which created a lot of unnecessary work for them and took them away from patching more important issues.
Second, it is important to qualify that I believe in the spirit of this but not in the execution. In cases where there is a lack of information about which prior versions are impacted, it is safer to assume that you are vulnerable and upgrade. This satisfies companies that want to take no chance while also helping companies that make a decision to use older versions. This is what I call “business logic” where it is policy driven, not potentially incorrect data driven.
Third, the biggest issue around this is the lack of information. This comes from several aspects of vulnerability disclosure including the time involved in testing prior versions, the time required to dig into commits to find when a vulnerability was introduced (for open source), and a general lack of attention to detail that comes with so many disclosures.
In the brief discussion with Bressers, after my response, he posited “so what’s worse, listing one singular version, or <= ? Two terrible choices”. He is correct that neither option is ideal, but the simple fact is that one is 100% correct in that context, and the other is sometimes correct. At VulnDB we have always strived for accuracy and include only what we know, with one caveat, and let customers use their own policy or business logic to assume the rest. The one caveat is that we do have a flag we can use that says “All prior”.
This allows us to list what we positively know as affected, possibly affected, or not affected, while not making assumptions through the addition of specific versions. One important thing to note is that we only use this flag if a vendor says that all prior are affected, even if we are reasonably sure they didn’t test that themselves. We do not use it if a researcher says it because of how often that happens including on sloppy short disclosures where it is clear they spent little time “researching” the issue.
Even with that functionality we have to be extremely careful. In the case above, we could not list 7.1.2-26 (not affected) and 7.1.2-25 (All prior versions affected) either. That would imply all versions prior to 7.1.2-25 which would include all of 6.x, 5.x, 4.x, and so on. In this case we know that 6.9.13-51 is not affected so that flag would be inaccurate.
There are several vulnerability databases that consistently made assumptions about all prior versions being affected, even when neither a researcher or a vendor said that. SecurityFocus’ Bugtraq ID Database (BID) was probably the worst offender, as well as the U.S. National Vulnerability Database (NVD) many years back. Secunia is another database that did it but they started locking down their information increasingly so meaning it is hard to find via archive sites, and I don’t have the time to go grep through the content of theirs I saved locally. Otherwise, here are a couple examples to illustrate my point.
SecurityFocus / Symantec / BID
VulnDB 37754 – FreeType base/ftbimap.c ft_bitmap_assure_buffer() Function Sbit Font Handling Buffer Overflow
From the release notes provided by the vendor:
Release Name: 2.3.4
Notes:
CHANGES BETWEEN 2.3.4 and 2.3.3
I. IMPORTANT BUG FIXES
– A serious bug in the handling of bitmap fonts (and bitmap
strikes of outline fonts) has been introduced in 2.3.3.
You can see it is very clear that the vulnerability was introduced in version 2.3.3 and fixed in 2.3.4 meaning a single version is vulnerable. However, notice that SecurityFocus reported this listing all prior versions including “0” and that wasn’t even a valid version.
National Vulnerability Database (NVD)
VulnDB 106055 – Linux Kernel /arch/x86/net/bpf_jit_comp.c Off-by-one Local Privilege Escalation
In this case, NVD got it right and wrong. Looking at their affected versions via the Common Platform Enumeration (CPE) strings, we can see they use CPE for 3.0-rc1 which is correct, as that was the first version the vulnerability was introduced in. However, at the end of the CPE strings they also use:
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
That represents “all versions” of Linux and is not accurate as the vulnerability was introduced in 3.0-rc1 and 3.0.16 is the fixing version. That means that 2.0 or 3.0.17 are not vulnerable but this string would label both as such if you use their metadata during automation.
Conclusion
Until we have technology that can automatically dive into commits or reverse engineer all versions of a piece of software we won’t have a perfect solution. But when presented with two or more possible solutions, where one is more accurate than the other, I certainly choose the more accurate one.