Open sekveaja opened 8 months ago
willmurphyscode
commented
8 months ago 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
commented
8 months ago 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
commented
8 months ago 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
commented
8 months ago 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.
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
Anything else we need to know?:
Environment:
grype version: 0.74.6cat /etc/os-releaseor similar): SLES 15 SP 5