False positives when installing both libcrypto, libssl 1.1 and 3 on alpine 3.19 #1843
Comments
|
Hi @remiville, Thanks for the report! The reason Grype is matching is that for OS packages (in this case APK packages) that have a source/upstream package, vulnerabilities against the source/upstream package are reported. In this case, the source upstream package is For example, for CVE-2023-0464, we have the following entry in the match database: Because libcrypto1.1. and libssl1.1 have openssl as their upstream at a version less than 3.1.0-r1, these packages are marked as vulnerable to CVE-2023-0464. Can you help me understand why you believe these are false positives? Is it because |
|
Hi @willmurphyscode, Thanks for your support, for example if we focus on CVE-2023-0464 (same story for other CVE listed previously):
I didn't have this issue when installing only libssl1.1 and libcrypto1.1 or only libssl3 and libcrypto3 packages, I've got the issue when installing both. |
|
Thanks for the response @remiville! Would you mind posting a Dockerfile that doesn't have the false positive? Was it on a different version of Alpine? I think what's going on is that we don't have the lower bound of the version constraint in the database correctly: select id, package_name, version_constraint, namespace
from vulnerability
where namespace like '%alpine%' and id = 'CVE-2023-0464';
id package_name version_constraint namespace
------------- ----------------- ------------------ -------------------------
CVE-2023-0464 openssl < 1.1.1t-r1 alpine:distro:alpine:3.14
CVE-2023-0464 openssl < 1.1.1t-r2 alpine:distro:alpine:3.15
CVE-2023-0464 openssl3 < 3.0.8-r1 alpine:distro:alpine:3.15
CVE-2023-0464 openssl < 1.1.1t-r1 alpine:distro:alpine:3.16
CVE-2023-0464 openssl3 < 3.0.8-r1 alpine:distro:alpine:3.16
CVE-2023-0464 openssl < 3.0.8-r1 alpine:distro:alpine:3.17
CVE-2023-0464 openssl1.1-compat < 1.1.1t-r1 alpine:distro:alpine:3.17
CVE-2023-0464 openssl < 3.1.0-r1 alpine:distro:alpine:3.18
CVE-2023-0464 openssl1.1-compat < 1.1.1t-r1 alpine:distro:alpine:3.18
CVE-2023-0464 openssl < 3.1.0-r1 alpine:distro:alpine:3.19
CVE-2023-0464 openssl < 3.1.0-r1 alpine:distro:alpine:edgeIn this case, we're scanning an image built from Alpine 3.19, and we have a package called "openssl" whose version is 1.1.1w-r1, so the row It's also worth noting that these are for different versions of Alpine - that is, you're installing packages from Alpine 3.16 onto Alpine 3.19; since it's an Alpine 3.19 image, Grype is doing to use the alpine:3.19 namespace to search for vulnerabilities. We have an open issue, #86, to make Grype pick a distro namespace on a per-package basis, but it's not always possible to tell from a package manager what namespace to use. I think this issue will just be fixed by emitting better version constraints when we build the database, so I'll start digging there. |
What happened:
On alpine I need:
tomcat-native 1.x relies on libcrypto1.1, libssl1.1
When I was on alpine 3.18 there were no issue (I suppose because alpine 3.18 already has libcrypto1.1, libssl1.1).
When I upgrade to 3.19 I have to explicitly install libcrypto1.1, libssl1.1 (1.1.1w-r1) from alpine 3.16 repo (even if I'm on alpine 3.19) because alpine 3.19 repo do not include these libraries (unlike alpine 3.18)
Doing this I have many many false positive (see below).
I think this is a consequence of installing both libcrypto3, libssl3 and libcrypto1.1, libssl1.1 despite these high CVE are part of version intervals not concerned by the versions I install.
Most of the time these CVE concern versions up to 1.1.1t (despite I install libcrypto1.1 1.1.1w-r1) or between [3.0, 3.0.12] or [3.1, 3.1.4] (despite I install libcrypto3 3.1.4-r6)
What you expected to happen:
Grype should not report these false positive and discern the usage libcrypto1.1 than libcrypto3.
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know?:
Environment:
grype version: v0.74.2cat /etc/os-releaseor similar):The text was updated successfully, but these errors were encountered: