-
Notifications
You must be signed in to change notification settings - Fork 546
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Grype doesn't take account OS distributor patch release #1541
Comments
@wagoodman Thank you so much for the hint, that solved one issue for the distro reference. I will update the finding and correct some information on the initial report information. |
There is a simple way to reproduce the problem at the rpm file and at the rpm extracted contents.
==> No vulnerability at the rpm level, as it has all information relate to the fix release see with rpm -qi python3-lxml-4.7.1-150200.3.10.1.x86_64.rpm
And syft provide this output:
==> 2 files lead to 4.7.1 from the contents of the rpm. From the OS distributor point of view this version and release python3-lxml-4.7.1-150200.3.10.1.x86_64.rpm has already the CVE fixed. From the tool point view, it isn't, because not all file has release name "-150200.3.10.1" Maybe Syft doesn't have Output from Syft:
|
This time I'm testing with another OS which is Red Hat 9.2. CVE-2022-2309, according to Red Hat, is fixed with RHSA-2022:8226 Conclusion At the end, we always get CVE reported to the problematic <version>. If Grype could check the current installed file is belong to patch rpm <version>-<patch release>, that would help not to report extra CVE, therefore, less false positive. Below are steps to reproduce the Red Hat rpm.
|
Hi @sekveaja, if I am understanding your report correctly, you are showing that when you scan the RPM itself, you get the correct results (one Medium vulnerability), and when you scan the contents of the manually-extracted RPM, you get an additional "High" vulnerability, which is a false positive, since the vulnerability has been backported to the older version. Right? I believe this is expected behavior, since as you have shown, when you scan the contents of the RPM but not the RPM itself, there is no information available for Syft or Grype to determine that the files came from an RPM. Around Grype 0.66 we added logic to filter out files provided by distro packages (#1387) -- so when you scan a container image, we should be doing the right thing and taking into account the distro's backports. I believe the results from your RHEL 9.2 experiment is expected behavior. If you are using a recent version of Grype and scanning a container image that includes this lxml package as an RPM, you should not see this false positive. Can you make sure I am understanding the issue correctly, and can you tell us what version of Grype you are using to scan the container images? Thanks! |
Hi @tgerla, Thank you for the explanation, what has been described in (#1387) is pretty much the same general issue with python-<any_package> that I experienced. I was using grype 0.69.1 on the previous test. To continue with my Red Hat example which has the same issue with SLES.
Comment: At first glance, with no vulnerability found, it seem to fix the issue. But wait to see test 2).
Comment: This is a false positive, according to REDHAT adviser https://access.redhat.com/errata/RHSA-2022:8226
Comment: The good thing with this new test, we have one package less
It eliminates "lxml 4.6.5 python CVE-2022-2309" but still have this vulnerability GHSA-wrxv-2j5q-m38w, which is fact related to CVE-2022-2309. This is probably the nature of Python package, once it is extracted, you won't see the "-release" information in their directory or files. I hope not to bring too much confusion, just want to contribute to improve Grype. Thanks! |
Hey @sekveaja, thanks for the updates. This helps a lot. Most of the behavior you're seeing is expected--differences between scans of the RPM itself and the directory of unpacked RPM contents is expected. But you are correct that the vulnerability shown in test 2 is indeed a false positive. We've dug into this pretty deeply and we have found an issue with the way we handle Flatpak-based package. We will be opening another issue to track this in the vunnel project, which is the tool responsible for parsing vulnerability data into a Grype database. Please stay tuned, and thank you very much for the analysis! It has helped us find some subtle issues. |
FYI we've captured the flatpak-related issue here anchore/vunnel#443 , which is a separate class of FP that is mentioned/discovered here but doesn't relate to the description. |
In terms of case 2, I'm able to reproduce with an old database
However with the latest DB and grype version I am not able to reproduce:
I think this means that the last open problem described in this issue is resolved 🎉 Please feel free to reopen if that is not the case |
What happened:
Scan a container that has only python3-lxml-4.7.1-150200.3.10.1.x86_64 installed, then, get the following: CVE-2022-2309
According to SUSE, CVE-2022-2409 issue has been patched with the following version 4.7.1-150200.3.10.1
See SUSE CVE reference: https://www.suse.com/security/cve/CVE-2022-2309.html
As for NVD, it is expected to have fix from version 4.9.1
https://nvd.nist.gov/vuln/detail/CVE-2022-2309
What you expected to happen:
If Grype compares the currently installed (4.7.1-150200.3.10.1 ) version against NVD resolution version, which is 4.9.1+, that will always generate a vulnerability.
Looking for information inside the container:
A) Verify what is installed in the container related to lmxl
B) Query the information of the package
C) Query the list of files in the RPM
D) Verify the content in PKG-INFO
E) Package that has installed file /usr/lib64/python3.6/site-packages/lxml-4.7.1-py3.6.egg-info/PKG-INFO
F) Run syft to verify the packages
Q1: Is CVE reported on lxml 4.7.1 is related to this file:
/usr/lib64/python3.6/site-packages/lxml-4.7.1-py3.6.egg-info/PKG-INFO?
If the logic is getting info from PKG-INFO, it miss the Release information in the file.
But this file is really part of the fix RPM from SUSE see E).
Q2: In this situation, how do you plan to fix this?
Other useful information:
When download and scan directly on the rpm file, it doesn’t show any vulnerability with warning:
“Unable to determine the OS distribution. This may result in missing vulnerabilities. You may specify a distro”
The right argument for SLES OS distribution ( Thanks to @wagoodman )
The text was updated successfully, but these errors were encountered: