False positives for recent CUPS vulnerability CVE-2024-47175

[dbrugman]

What happened:
When scanning several images Grype reported cups client-library packages ('cups-libs' / 'libcups2') being impacted by CVE-2024-47175. However, the client library packages are not impacted, only the (depending on the distribution) 'cups', 'cups-filters' and 'libppd' packages.

What you expected to happen:
Since the client library packages are not impacted I expected those not to appear in the scan results as being vulnerable.

How to reproduce it (as minimally and precisely as possible):
This can be reproduced, for example, using a slightly older Hazelcast Enterprise image (which is based on Red Hat Enterprise 9.4):

grype --by-cve hazelcast/hazelcast-enterprise:5.5.0-SNAPSHOT | grep CVE-2024-47175

It will report the following:

cups-libs                   1:2.3.3op2-27.el9_4                                 rpm           CVE-2024-47175  High

However, this package provides the libraries libcups.so.2 and libcupsimage.so.2, which are not impacted. The Red Hat advisory for release 9 also explicitly states that only the packages cups and cups-filters are impacted. Source: https://access.redhat.com/security/cve/CVE-2024-47175.

The same applies to Ubuntu images that have libcups2 installed. We have a proprietary image based on ubuntu:22.04 (unfortunately I cannot share), which has the following package installed:

libcups2:amd64                2.4.1op1-1ubuntu4.10

Grype will incorrectly flag that package as being impacted by CVE-2024-47175. It's again a non-vulnerable client library, the only Ubuntu 22.04 package that is impacted is cups. Source: https://ubuntu.com/security/CVE-2024-47175

Anything else we need to know?:
For the Red Hat cups-lib package I did make sure it does not come with the vulnerable function ppdCreatePPDFromIPP2. I checked the sources, and created debug versions of the libraries and verified that the name does not appear in the debug symbols.

I also checked the Grype vulnerability database. It - correctly - only lists the cups, cups-filters and libppd packages as being vulnerable, so not sure why the client libraries are being matched. Note that I'm running Grype with vanilla settings (I did not enable CPE matching, for example).

Environment:

• Output of grype version:
  Application: grype
  Version: 0.81.0
  BuildDate: 2024-09-25T16:57:40Z
  GitCommit: 641982f
  GitDescription: v0.81.0
  Platform: linux/amd64
  GoVersion: go1.23.1
  Compiler: gc
  Syft Version: v1.13.0
  Supported DB Schema: 5

• OS (e.g: cat /etc/os-release or similar):
  NAME="Ubuntu"
  VERSION="20.04.6 LTS (Focal Fossa)"
  ID=ubuntu
  ID_LIKE=debian
  PRETTY_NAME="Ubuntu 20.04.6 LTS"
  VERSION_ID="20.04"
  HOME_URL="https://www.ubuntu.com/"
  SUPPORT_URL="https://help.ubuntu.com/"
  BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
  PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
  VERSION_CODENAME=focal
  UBUNTU_CODENAME=focal

[westonsteimel]

Thanks for the report. This is a known limitation of the current distro package matching strategy that can result in false positives. If you look at the full json output you'll see in the match details section that this is an exact-indirect-match. This means that it didn't find any matches on the specific package cups-libs, but it did find a match on the "upstream" package cups that cups-libs is derived from (using the rpm relationship metadata it found when constructing the sbom). This is particularly necessary for distros where the vulnerability data is only reported on the source package level. I'm not certain if there are currently any options exposed to allow tailoring whether or not it filters exact-indirect-match entries in the results for specific package types or not. I'll let others comment on what a possible solution may be going forward.

[dbrugman]

Thanks for the quick response @westonsteimel ! Q: "where the vulnerability data is only reported on the source package level." - wouldn't it be possible to only apply indirect matching if the vulnerability is indeed only reported on a source package?

[westonsteimel]

Eventually I think that could be an option, when constructing the db, consult a source of known package metadata within a particular ecosystem to understand whether indirect matching may be required or not, but unfortunately the current grype database schema would not be able to accomodate that. We are however working towards a new db schema that is much more flexible and could I believe accomodate the addition of such data

[westonsteimel]

Additionally, we are working to switch over the the CSAF data source for RHEL vuln data which also includes VEX data for specifying things which are not affected by a particular vuln. I'm not sure if that would help in this particular case (I haven't looked at if they have VEX data for this which would explicitly exclude cups-libs), but that is another avenue we are considering with the next grype db schema

[dbrugman]

That new db schema sounds promising, thanks for sharing.
I was not yet aware of CSAF - interesting, I'll look into it. I did find the file for RHEL 9 for this particular vulnerabilityL https://security.access.redhat.com/data/csaf/v2/advisories/2024/rhsa-2024_7346.json

I'm not familiar with the format, but I did not see anything that looks like exclusions, or any reference to 'cups-libs'.

[westonsteimel]

It doesn't look like they have any not_affected entries for it in this case, but the file with the VEX statements is at https://security.access.redhat.com/data/csaf/v2/vex/2024/cve-2024-47175.json