Tomcat8 / CVE-2020-1938 / CVE-2019-17569

Hi,
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:

  1. Unauthenticated (remote) scan (means a “full” scan via the openvas scanner)
  2. Authenticated scan via SSH (means a “full” scan via the openvas scanner)
  3. A mixture of 1. and 2.
  4. 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:

https://docs.greenbone.net/GSM-Manual/gos-21.04/en/reports.html#quality-of-detection-concept

Hello,

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. cpe:/a:apache:tomcat:8.5.50).

The report of the following detection VT should bring some clarity on this:

Name: Apache Tomcat Detection Consolidation
OID: 1.3.6.1.4.1.25623.1.0.107652

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: 1.3.6.1.4.1.25623.1.0.107652
cpe:/a:apache:tomcat:8.5.50

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:

  1. Any issues / problems from GVM side (e.g. outdated versions of components, other problems with the feed sync, …)
  2. Has the filter really be adjusted to show results for VTs with a QoD < 70%
  3. 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