False positives when installing both libcrypto, libssl 1.1 and 3 on alpine 3.19 about grype HOT 3 OPEN

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 openssl.

For example, for CVE-2023-0464, we have the following entry in the match database:

id             package_name  version_constraint
-------------  ------------  ------------------
CVE-2023-0464  openssl       < 3.1.0-r1

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 libssl1.1 and libcrypto1.1 should be considered different packages than libssl and libcrypto, and not just older versions?

from grype.

Hi @willmurphyscode,

Thanks for your support, for example if we focus on CVE-2023-0464 (same story for other CVE listed previously):

• NVD: https://nvd.nist.gov/vuln/detail/CVE-2023-0464
• alpine: https://security.alpinelinux.org/vuln/CVE-2023-0464
  We can see in these details that the CVE concerns libssl1.1 and libcrypto1.1 only for version < 1.1.1u, but here I install a more recent version without the CVE: 1.1.1w-r1

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.

from grype.

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:edge

In 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 CVE-2023-0464 openssl < 3.1.0-r1 alpine:distro:alpine:3.19 matches. From reading https://security.alpinelinux.org/vuln/CVE-2023-0464, it seems like the version constraint should be >= 3.1.0 < 3.1.1, which would not have a match. This might be an issue in the Vunnel provider for Alpine.

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.

from grype.