False Positive: Openssl CVE-2022-2068, CVE-2022-1292, CVE-2021-3711 in SUSE Enterprise 15 SP5

[sekveaja]

What happened:

Run grype on container that has openssl file, the tool report many CVE on it.

NAME INSTALLED FIXED-IN TYPE VULNERABILITY SEVERITY
openssl 1.1.1 binary CVE-2022-2068 Critical
openssl 1.1.1 binary CVE-2022-1292 Critical
openssl 1.1.1 binary CVE-2021-3711 Critical
openssl 1.1.1 binary CVE-2023-4807 High

What you expected to happen:

According to SUSE Advisory, those critical CVE are fixed from release
libopenssl1_1 >= 1.1.1l-150500.15.4
openssl-1_1 >= 1.1.1l-150500.15.4

See https://www.suse.com/security/cve/CVE-2022-2068.html

The container has openssl-1_1-1.1.1l-150500.15.4 rpm installed.
In the normal and wanted behavior, the tool should not report those CVE as condition is met from SUSE Advisory criteria.
We test with grype 0.74.6 with --distro sles:15.5 argument.

It seems that RPMs once it contents is installed and extracted in the container, syft output that feed Grype has no way to tell file A, file B, file C,.... is coming from a patch, hence, Grype generate output with false output, as it has no reference or context.

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

This is just a way to reproduce the issue from the command line by extracting the contents from the RPM.

*** Some nuance need to follow, in a container when a RPM packaged is installed, if you go in the container, you are able to validate with the rpm command (cli) file A, file B,... belong to which package and patch.

Below example, it just to extract the rpm contents with cpio cli , thus, not installing the rpm.
It can't run rpm command to verify file A, file B,.. belonging package.

However, the false positive seen on the container has the same result here as the extract contents RPM content.
I hope that will provide you some hint to work on it.

The example openssl-1_1-1.1l-150500.17.9.1 is even more recent and still show the same issue.

1. Get this file and unzip
   openssl-1_1-1.1.1l-150500.17.9.1.x86_64.rpm.zip

2. mkdir openssl, cd openssl

3. Extract openssl-1_1-1.1.1l-150500.17.9.1.x86_64.rpm
   rpm2cpio openssl-1_1-1.1.1l-150500.17.9.1.x86_64.rpm | cpio -idvm

4. cd ..
   grype --distro sles:15.5 ./openssl

NAME     INSTALLED  FIXED-IN  TYPE    VULNERABILITY   SEVERITY
openssl  1.1.1                binary  CVE-2022-2068   Critical
openssl  1.1.1                binary  CVE-2022-1292   Critical
openssl  1.1.1                binary  CVE-2021-3711   Critical
openssl  1.1.1                binary  CVE-2023-4807   High
openssl  1.1.1                binary  CVE-2023-0464   High
openssl  1.1.1                binary  CVE-2023-0286   High
openssl  1.1.1                binary  CVE-2023-0215   High
openssl  1.1.1                binary  CVE-2022-4450   High
openssl  1.1.1                binary  CVE-2022-0778   High
openssl  1.1.1                binary  CVE-2021-3712   High
openssl  1.1.1                binary  CVE-2021-23840  High
openssl  1.1.1                binary  CVE-2019-1543   High
openssl  1.1.1                binary  CVE-2024-0727   Medium
openssl  1.1.1                binary  CVE-2023-5678   Medium
openssl  1.1.1                binary  CVE-2023-3817   Medium
openssl  1.1.1                binary  CVE-2023-3446   Medium
openssl  1.1.1                binary  CVE-2023-2650   Medium
openssl  1.1.1                binary  CVE-2023-0466   Medium
openssl  1.1.1                binary  CVE-2023-0465   Medium
openssl  1.1.1                binary  CVE-2022-4304   Medium
openssl  1.1.1                binary  CVE-2022-2097   Medium
openssl  1.1.1                binary  CVE-2021-4160   Medium
openssl  1.1.1                binary  CVE-2021-3449   Medium
openssl  1.1.1                binary  CVE-2021-23841  Medium
openssl  1.1.1                binary  CVE-2020-1971   Medium
openssl  1.1.1                binary  CVE-2019-1551   Medium
openssl  1.1.1                binary  CVE-2019-1549   Medium
openssl  1.1.1                binary  CVE-2019-1547   Medium
openssl  1.1.1                binary  CVE-2018-0735   Medium
openssl  1.1.1                binary  CVE-2018-0734   Medium
openssl  1.1.1                binary  CVE-2019-1563   Low
openssl  1.1.1                binary  CVE-2019-1552   Low

Anything else we need to know?:

Environment:

• Output of grype version: 0.74.6
• OS (e.g: cat /etc/os-release or similar): SLES 15 SP 5

[willmurphyscode]

Hi @sekveaja,

Thanks for the report? It sounds like there is some subtlety to producing this artifact correctly to exhibit the false positive you reported.

It sounds like, basically, I should start with a SUSE-based docker image, download an RPM containing openssl, and then unpack the RPM manually without using a normal installation process, and then scan that resulting image?

[sekveaja]

Hi @willmurphyscode,

In fact, if you a SUSE container that has openssl inside, it is sufficient to reproduce.
Because I have a custom container that can't be shared, I can only pin-point the issue and lead into which file or binary that is causing false positive from the log file.
Knowing the file or binary, you can verify which RPM package and version.
And knowing the RPM package and if you have access to the RPM.

1. We can scan at the RPM package which normally has information of the patch. And false positive is not show if the patch version is complied to SUSE Advisory.

2. We can extract contents of the RPM with rpm2cpio & cpio, then scan.
   And you'll get the same output like the one scanning on the container relating to false positive.

   But the nuance that I mentioned earlier is here.
   If you go in the container, you run rpm -qf <file>, it will give the RPM package name with
   <version>-<patch-id>. As in the container, RPM package are installed from the OS package manager.
   Therefore, each file inside that container eco-system has reference to which RPM package is belonged
   to.
   Where extracting RPM contents with rpm2cpio & cpio, is not an installation, when running rpm -qf
   <file> will get no reference of the RPM package.

   So far, what is observed with false positive, the tool is able to lead file that is causing the issue
   but has no reference or context if the file is belonged to a specific RPM package has patches applied.
   Without context at the file level to the RPM, I believe false positive will always be generated.

[tgerla]

Hi @sekveaja, thanks for the details. If you unpack the RPM with rpm2cpio and "install" the binaries manually, Syft indeed won't know they're attached to an RPM. But if you install the RPM with the package manager, Syft should be able to use the information the RPM database to de-duplicate the binary matches. So we need to know what files are owned by that openssl RPM, and we also need to know the specific paths of the results that are found using the "binary" cataloger.

How are you normally installing this RPM? Since you can't share the container, can you share the SBOM in JSON format? That would help us narrow down the problem. Thank you!

[sekveaja]

Hi @tgerla,

It is good to know that Syft can track file that is belonged to a specific rpm based on the RPM database.
Can Syft know the file or binary has been patched since the patch information is at the RPM package level only?
From what I see at the granularity level, it loose track of the patch from the OS distributor.
And vulnerability is always pointing to specific file or binary which is at the granularity level.

To answer to your question:: How are you normally installing this RPM?
All RPM packages are installed and extracted with zypper to the container.

Does zypper is supported by Syft?
Most tickets that I opened, are with SUSE OS, therefore, zypper is the package manager.