I’ve been running authenticated scans on a debian 11 machine. It has Tomcat 8.5.50 installed - the respective CPE is being detected correctly.
I would’ve expected to see (at least) both CVE-2020-1938 and CVE-2019-17569, but I’m getting only CVE-2020-1938 back.
Is there an obvious reason for this I am missing?
Hello and welcome to this community portal.
Could you please provide some additional information on the kind of scan you did:
- Unauthenticated (remote) scan (means a “full” scan via the openvas scanner)
- Authenticated scan via SSH (means a “full” scan via the openvas scanner)
- A mixture of 1. and 2.
- A scan via the “CVE scanner” (which is some kind of “virtual prognosis” scan)
But from a first glance (if 1. or 3. was done) the difference is that for CVE-2020-1938 an “active” check exists which is checking the flaw remotely and in a reliable way (means a high “qod”) while for CVE-2019-17569 only a “version” check exists which is checking the flaw remotely but in an unreliable way (means a low “qod”).
To get a result for the version check of CVE-2019-17569 on Linux systems you would need to lower the QoD in the filter of your report to show results with a QoD of < 70 % (due to the availability of backport on Linux systems).
More info on the QoD topic is available here:
I’m running authenticated scans via SSH. I’ve also lowered the qod to 0%, but still don’t see CVE-2019-17569. Even a CVE scan doesn’t show CVE-2019-17569, although the CPE is detected correctly. If CVE-2019-17569 only had a version check, this should pop up.
From a first glance i can’t see anything wrong in the version check for “CVE-2020-1938”. But note that for version checks not only the CPE itself (e.g.
cpe:/a:apache:tomcat) but also the version within it needs to be detected and reported (e.g.
The report of the following detection VT should bring some clarity on this:
Name: Apache Tomcat Detection Consolidation
If this doesn’t detect e.g. a version the version checks can’t work. There might be also other problems (e.g. outdated versions of GVM) playing a role here.
It finds the full version:
Detected Apache Tomcat Version: 8.5.50 Location: 8080/tcp CPE: cpe:/a:apache:tomcat:8.5.50 Concluded from version/product identification result: Apache Tomcat Version 8.5.50
Details: Apache Tomcat Detection Consolidation OID: 220.127.116.11.4.1.25618.104.22.168652
The feeds are also up to date and the NVTs that should be able to detect CVE-2019-17569 are available in the NVT list.
I did a short cross-check against such a 8.5.50 installation and this works as expected from NASL side:
Detected Apache Tomcat Version: 8.5.50 Location: 8081/tcp CPE: cpe:/a:apache:tomcat:8.5.50 Concluded from version/product identification result: Apache Tomcat Version 8.5.50 Concluded from version/product identification location: http://<redacted>:8081/RELEASE-NOTES.txt
Installed version: 8.5.50 Fixed version: 8.5.51 Installation path / port: 8081/tcp
A few things to check:
- Any issues / problems from GVM side (e.g. outdated versions of components, other problems with the feed sync, …)
- Has the filter really be adjusted to show results for VTs with a QoD < 70%
- The detection also seems to not happen via a SSH login, you can cross-check the requirements following Hint: Verify target configuration / access for authenticated (LSC) scans