False Positive on ELSA-2022-4803

[navzen2000]

What happened: Grype reported ELSA-2022-4803 for below package on x86-64 linux

NAME INSTALLED FIXED-IN TYPE VULNERABILITY SEVERITY rsyslog 8.24.0-57.0.1.el7_9.3 0:8.24.0-57.0.4.el7_9.3 rpm ELSA-2022-4803 High

What you expected to happen: ELSA-2022-4803 is already fixed in rsyslog-8.24.0-57.0.1.el7_9.3.x86_64.rpm This is a false positive on x86-64 linux

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:

Environment:

• Output of grype version:

• Application: grype Version: 0.45.0 Syft Version: v0.52.0 BuildDate: 2022-08-03T15:18:36Z GitCommit: 8fe761b41ffc280e58e82b7fbba4d0d1a05aeb91 GitDescription: v0.45.0 Platform: linux/amd64 GoVersion: go1.18.4 Compiler: gc Supported DB Schema: 4

• 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]

Hi @navzen2000, thanks for reporting this issue.

Are you able to include some specific steps to reproduce? For example a Dockerfile or a link to a public image that exhibits the false positive would be a big help. I'm guessing this was observed on a RedHat-like system, since the package found is an RPM, but without a bit more information, we won't be able to investigate this.

[navzen2000]

Hi @willmurphyscode, thanks for acknowledging $ grype version Application: grype Version: 0.62.3 Syft Version: v0.83.0 BuildDate: 2023-06-05T21:34:29Z GitCommit: 3865f4cc1dfcdcefbb7009400df153f24b18c772 GitDescription: v0.62.3 Platform: linux/amd64 GoVersion: go1.19.9 Compiler: gc Supported DB Schema: 5

Check this out:

grype container-registry.oracle.com/os/oraclelinux:7|grep rsyslog ✔ Vulnerability DB [no update available] ✔ Loaded image ✔ Parsed image ✔ Cataloged packages [207 packages] ✔ Scanning image... [15 vulnerabilities] ├── 0 critical, 8 high, 7 medium, 0 low, 0 negligible └── 14 fixed NAME INSTALLED FIXED-IN TYPE VULNERABILITY SEVERITY rsyslog 8.24.0-57.0.1.el7_9.3 0:8.24.0-57.0.4.el7_9.3 rpm ELSA-2022-4803 High

Refer to : https://linux.oracle.com/errata/ELSA-2022-4803.html Fix is present in rsyslog-8.24.0-57.0.1.el7_9.3.x86_64.rpm

[willmurphyscode]

Thanks @navzen2000! I'm able to reproduce with those steps. (I'm passing a platform to grype, since I'm on an M1 and it seems the arm64 image is not vulnerable: grype --platform linux/amd64 container-registry.oracle.com/os/oraclelinux:7|grep -i rsyslog).

Here's the matchDetails node from Grype's output with -o json:

   "matchDetails": [
    {
     "type": "exact-direct-match",
     "matcher": "rpm-matcher",
     "searchedBy": {
      "distro": {
       "type": "oraclelinux",
       "version": "7.9"
      },
      "namespace": "oracle:distro:oraclelinux:7",
      "package": {
       "name": "rsyslog",
       "version": "0:8.24.0-57.0.1.el7_9.3"
      }
     },
     "found": {
      "versionConstraint": "< 0:8.24.0-57.0.4.el7_9.3 (rpm)",
      "vulnerabilityID": "ELSA-2022-4803"
     }
    }
   ],

I wonder whether (rpm) on the end of the versionConstraint is preventing correct version comparison? I will need to keep investigating. Thanks again for the repro steps!

[westonsteimel]

@willmurphyscode , this is because it doesn't currently account for architecture differences so it takes the max fix among them. So for x86_64 the fix version was rsyslog-8.24.0-57.0.1.el7_9.3 but for aarch64 it was rsyslog-8.24.0-57.0.4.el7_9.3 so it will currently use the higher value

[westonsteimel]

It might be possible to create another rpm package qualifier for architecture or something so we can capture both and match accordingly but probably needs some thought