Cannot Detect Any Vulnerabilities

[BugHunter1000]

Thanks for at least the idea of building this, it's a wonderful concept, even though I haven't been able to get it to work at all.

I have done this:

Download Firefox on Alpine Linux
Observe that it is version 81
Observe that it is indeed vulnerable: https://www.mozilla.org/en-US/security/advisories/mfsa2020-45/
pullcves pull
find / -type f -perm -o+x > /tmp/cvecheck.tmp
cat /proc/version >> /tmp/cvecheck.tmp
cvechecker -b /tmp/cvecheck.tmp

I get no output.

What do?

[sjvermeu]

Hi BugHunter1000,

For firefox this was to be expected as I had no version detection rules for firefox listed. I've done that now, so the moment you do a pullcves pull (and the version_url parameter in /etc/cvechecker.conf points to https://raw.github.com/sjvermeu/cvechecker/master/versions.dat) it should have the knowledge for detecting Firefox version. So then, calling cvechecker -b ... on your list should detect it.

Now, you mention you get no output at all, which is weird because it should detect a number of rules, including at least the Linux kernel one:

~# cvechecker -b scanlist.txt 
 - Found match for /proc/version:	cpe:2.3:o:linux:linux_kernel:5.9.11:*:*:*:*:*:*:*
...

Is the output of pullcves pull, especially when you run it the second time around, similar/the same as the following?

~# pullcves pull
Downloading nvdcve-1.1-Modified.json.gz... ok (not downloaded, same file)
Downloading versions.dat... ok (not downloaded, same file)

If it is, is trying to get the CPE information from /proc/version working?

~# cvechecker -f /proc/version
 - Found match for /proc/version:	cpe:2.3:o:linux:linux_kernel:5.9.11:*:*:*:*:*:*:*

If it is, then try the firefox one:

~# cvechecker -f /opt/firefox/firefox-bin
 - Found match for /opt/firefox/firefox-bin:	cpe:2.3:a:mozilla:firefox:83.0:*:*:*:*:*:*:*

If that works out fine, then try the last three steps again of your report (the find , cat /proc/version and cvechecker -b one) to see if that now works fine.

[BugHunter1000]

First of all thank you for giving me such a detailed reply and for your time and effort here.

I've done: $ pullcves pull $ find / -type f -perm -o+x > /tmp/cvecheck.tmp $ cvechecker -b /tmp/cvecheck.tmp

This time around I get dozens of "- Found match for..." ranging from unzip to dbus to pam, and I don't know if this is an enumeration of all whitelisted packages, or if I simply need to run an update, I have not done one recently (in the last few days) so perhaps the system (in a vm) is out of date.

I have a couple of followup questions, but first I will address the questions you sent:

1. Are the version_url values the same?
2. Am I detecting at least one found value?
3. Does the output of my pullcves pull match yours?
4. Can I get information from /proc/version for CPE's and what is it?
5. I think the rest of the ambiguities above are addressed by (4) but if the replies below do not fulfill your curiosity please reply back and I will adjust my answers.

1: My version URL does match. It is https://raw.github.com/sjvermeu/cvechecker/master/versions.dat

2: I am now detecting a whole host of found values, as I mentioned in my summary reply above.

3: pullcves pull resulted in: Downloading nvdcve-2.0-Modified.xml... gunzip: nvdcve-2.0-Modified.xml.gz: No such file or directory ok (not downloaded, same file) Downloading versions.dat... ok (downloaded) Loading in versions.dat in cvechecker. Loading in new version data file... This was strange to me because it has been days since opening this VM, so if you could give me the locations of these files, I could reply with md5sum tails to check if they were actually brought up to date.

4: running cvechecker -f /proc/version gives: - Found match for /proc/version: cpe:/o:linux:linux_kernel:5.4.72-0-lts:::

I have a couple of followup questions if you would be kind enough to address them when you have a few minutes:

A. You mentioned above having to set up a manual whitelist of "version detection rules" per-application. This is not at all what I expected cvechecker to provide, and I am worried about its usefulness now - can you go into more detail about what the scope of what it illuminates is, and how the tool works procedurally, and in what cases it works and in what cases it does not detect a vulnerability? I was not expecting a whitelist approach, but it sounds like that is what is being done?

B. Could you also go a little further into detail about the way you pull CVE data, and on what sources you rely? I was thinking it came straight from Alpine but it looks like maybe you have a larger source that you use for comparisons?

[sjvermeu]

Before going on your additional questions, one observation I have from your feedback is that the system is attempting to download the XMLs. The XML feeds have been disabled a while ago by NVD/NIST, and are now only available through JSON. cvechecker version 4 supports/uses the JSONs, you might still be running an older version.

As for your follow-up question: the versions.dat file is a file that contains expressions on how to detect the software on your system. This detection results in a list of CPEs, which are identifiers for the software found. For instance, for the /proc/version one the output in your case is cpe:/o:linux:linux_kernel:5.4.72-0-lts::: which is the CPE for the Linux kernel, for that exact version.

These CPE ids are needed because the vulnerability information online (the CVEs, i.e. what is published every time a vulnerability is found and reported to the community at large) uses CPEs to tell which software is affected by the vulnerability and which software isn't.

What cvechecker does is map the two together, i.e. the list of CPEs found on your system with the list of CVEs published online, and tell you what software is vulnerable.

There are of course a number of shortcomings with this. First, if the versions.dat file that cvechecker uses does not contain an expression to generate a CPE for one of the softwares you have (as was the case with firefox), it will not generate a CPE, and thus will also not be able to report a vulnerability on this.

Second, cvechecker uses simple rules to obtain the version (basically put, it looks for files/binaries that start with or contain a common identifier, like "firefox" in case of the firefox browser, and then captures the strings out of the binary and matches it against an expression registered in versions.dat). Hence, it can contain false positives (say you have a binary called firefox-chromecast-plugin.so then cvechecker might consider it part of firefox, try to fetch a version - which might then be completely irrelevant, like 1.0 - and then assume that you have firefox version 1.0 on your system).

A third shortcoming is that there are even software titles out there that cvechecker currently cannot generate anything useful for, like with Java applications that are only distributed as *.jar files. The reason is that these files are compressed archives, so trying to obtain the strings from it will not yield anything useful.

Now, cvechecker is written with multiple possible extractions in mind - the strings-based one is just the only one implemented for now. If other means come up they can be added as well.

The detection of the installed software is however not mandatory to use cvechecker. Rather than providing a list of binaries to scan (with the -b option) you can also pass on a file that already contains CPEs. In this case, you're telling cvechecker "don't bother trying to find out what software I have, here is the list for you". This is done with the -w (watchlist) option. If a Linux distribution can easily provide the CPE ids for the installed software, then this might even be preferred, because it will contain more accurate information. However, except for Red Hat Enterprise Linux, I'm not aware of Linux distributions that do this completely.

As for pulling CVE data: this is obtained from https://nvd.nist.gov/ and has nothing to do with the Linux distribution on which cvechecker is running.