False Positive: CVE-2021-3521 reported against rpm-4.14.3-26.el8.x86_64 on Oracle Linux 8

[navzen2000]

What happened:
Grype reported a false positive against rpm-4.14.3-26.el8.x86_64 on Oracle Linux 8

rpm 4.14.3 python CVE-2021-20266 Medium
rpm 4.14.3 python CVE-2021-3421 Medium
rpm 4.14.3 python CVE-2021-3521 Medium
rpm 4.14.3 python CVE-2021-35937 Medium
rpm 4.14.3 python CVE-2021-35938 Medium
rpm 4.14.3 python CVE-2021-35939 Medium

What you expected to happen:
https://linux.oracle.com/errata/ELSA-2022-0368.html

How to reproduce it (as minimally and precisely as possible):
grype container-registry.oracle.com/os/oraclelinux:8
Anything else we need to know?:
Grype is not reporting CVEs correctly for OS packages
Environment:

• Output of grype version:

• Application: grype
  Version: 0.63.0
  Syft Version: v0.84.0
  BuildDate: 2023-06-21T16:11:07Z
  GitCommit: ca79c2a
  GitDescription: v0.63.0
  Platform: linux/amd64
  GoVersion: go1.19.10
  Compiler: gc
  Supported DB Schema: 5

• OS (e.g: cat /etc/os-release or similar):
  NAME="Oracle Linux Server"
  VERSION="7.6"
  ID="ol"
  VARIANT="Server"
  VARIANT_ID="server"
  VERSION_ID="7.6"
  PRETTY_NAME="Oracle Linux Server 7.6"
  ANSI_COLOR="0;31"
  CPE_NAME="cpe:/o:oracle:linux:7:6:server"
  HOME_URL="https://linux.oracle.com/"
  BUG_REPORT_URL="https://bugzilla.oracle.com/"

ORACLE_BUGZILLA_PRODUCT="Oracle Linux 7"
ORACLE_BUGZILLA_PRODUCT_VERSION=7.6
ORACLE_SUPPORT_PRODUCT="Oracle Linux"
ORACLE_SUPPORT_PRODUCT_VERSION=7.6

[willmurphyscode]

Thanks for the report @navzen2000!

This is interesting. https://nvd.nist.gov/vuln/detail/CVE-2021-3521 is against RPM itself, before version 4.17.1. Checking the version of RPM in the oracle linux 8 image:

❯ docker run container-registry.oracle.com/os/oraclelinux:8 rpm --version
RPM version 4.14.3

So it seems like the image does indeed have this vulnerability. However, looking at the report, it looks like grype is reporting this vulnerability against an the python RPM bindings:

CVE-2021-3521 from nvd:cpe (Medium)
There is a flaw in RPM's signature functionality. OpenPGP subkeys are associated with a primary key via a "binding signature." RPM does not check the binding signature of subkeys prior to importing them. If an attacker is able to add or socially engineer another party to add a malicious subkey to a legitimate public key, RPM could wrongly trust a malicious signature. The greatest impact of this flaw is to data integrity. To exploit this flaw, an attacker must either compromise an RPM repository or convince an administrator to install an untrusted RPM or public key. It is strongly recommended to only use RPMs and public keys from trusted sources.
URLs:
- https://nvd.nist.gov/vuln/detail/CVE-2021-3521
- https://access.redhat.com/security/cve/CVE-2021-3521
- https://bugzilla.redhat.com/show_bug.cgi?id=1941098
- rpm-software-management/rpm@bd36c5d
- rpm-software-management/rpm#1795
- https://security.gentoo.org/glsa/202210-22
Matched packages:
Package: rpm, version: 4.14.3 (type: python)
PURL: pkg:pypi/[email protected]
CPE match on cpe:2.3:a:rpm:rpm:4.14.3:*:*:*:*:*:*:*
Evidenced by:
- nvd:cpe:CVE-2021-3521 evidence at /usr/lib64/python3.6/site-packages/rpm-4.14.3-py3.6.egg-info (artifact ID: a5c78e59349331b5)

(Summary created using the still-in-developmentgrype explain command, see #1342; feedback welcome)

So I think there are basically two things going on here that should be different:

1. Grype is reporting vulnerabilities against the python bindings for RPM that should be reported against RPM itself
2. Grype is not reporting this vulnerability against the rpm executable itself, but should be.

@navzen2000 is that what you meant by "Grype is not reporting CVEs correctly for OS packages"?

[navzen2000]

@willmurphyscode
Image rpm does not have this vulnerability because that finding has to be correlated with ELSA as well
https://linux.oracle.com/errata/ELSA-2022-0368.html
OL issues are fixed as per ELSA that contain reference to CVE in NVD
My concern is that CVE is incorrectly reported after looking at the ELSA

Please let me know if you think likewise.

[willmurphyscode]

@navzen2000 that makes sense. I think what grype is doing here is (1) correctly not reporting CVE-2021-3521 on the evidence of rpm itself, because the ELSA data reports a fixed version, but then (2) incorrectly reporting CVE-2021-3521 because one of the CPEs for the python RPM bindings that syft generates, specifically cpe:2.3:a:rpm:rpm:4.14.3:*:*:*:*:*:*:*, matches the CPE at https://nvd.nist.gov/vuln/detail/CVE-2021-3521. @westonsteimel do you agree that's what's likely happening?

[westonsteimel]

Yes, that seems likely

[westonsteimel]

@willmurphyscode - addressing #1373 would fix this I believe

[willmurphyscode]

I think this may have been addressed by the change the removed CPE matching by default from most ecosystems scanned by grype.

Here are the results of doing this scan today:

$ grype -q container-registry.oracle.com/os/oraclelinux:8
NAME             INSTALLED         FIXED-IN                  TYPE    VULNERABILITY        SEVERITY
gnutls           3.6.16-8.el8_9.1  10:3.6.16-8.el8_9.1_fips  rpm     ELSA-2024-12135      Medium
gnutls           3.6.16-8.el8_9.1  10:3.6.16-4.0.1.el8_fips  rpm     ELSA-2022-9221       Medium
libgcrypt        1.8.5-7.el8_6     10:1.8.5-7.el8_6_fips     rpm     ELSA-2022-9564       High
libgcrypt        1.8.5-7.el8_6     10:1.8.5-6.el8_fips       rpm     ELSA-2022-9263       Medium
openssh          8.0p1-19.el8_8    0:8.0p1-19.el8_9.2        rpm     ELSA-2024-0606       Medium
openssh-clients  8.0p1-19.el8_8    0:8.0p1-19.el8_9.2        rpm     ELSA-2024-0606       Medium
openssh-server   8.0p1-19.el8_8    0:8.0p1-19.el8_9.2        rpm     ELSA-2024-0606       Medium
setuptools       39.2.0            65.5.1                    python  GHSA-r9hx-vwmv-q579  High

None of these are reported against the Python package rpm 4.14.3. I'm going to close this issue since I believe we no longer find these false positives, but please let us know if we've missed something. Thanks!