False positives for packages installed from RH EUS streams

[bainsy88]

Summary

False positive is caused because Clair finds the security notice for RHEL 8 rather than for example RHEL 8.4 Extended support

Example

Openssl has a vulnerability CVE-2022-0778 which was fixed in the 8.4 extended support stream in openssl-1.1.1g-16.el8_4.src.rpm. However Clair finds the RHEL 8 security notice which states the fix is in openssl-1.1.1k-6.el8_5.src.rpm.

As 1.1.1g-16 is deemed a lower version than openssl-1.1.1k-6 it is marked as vulnerble to the CVE.

I think the core of issue is Clairs ability to find the correct security notice.

Recreate

The following Dockerfile can be used to produce an image that contains many of these false positives

FROM registry.access.redhat.com/ubi8/ubi:8.4

## Commented out as only needed if you building on a non RHEL box or one that doesn't have the correct subscriptions
#RUN --mount=type=secret,id=RHEL_SUBSCRIPTION_USER --mount=type=secret,id=RHEL_SUBSCRIPTION_PASSWORD \
    subscription-manager register --username=$(cat /run/secrets/RHEL_SUBSCRIPTION_USER) --password=$(cat /run/secrets/RHEL_SUBSCRIPTION_PASSWORD) --auto-attach

RUN dnf upgrade -y --repo=rhel-8-for-x86_64-baseos-eus-rpms --releasever=8.4

Interested in whether there is something we can do to help Clair determine the correct stream as a user or if this is a bug/missing feature on the Clair side

[hdonnay]

I suspect this is because of claircore's (poor) heuristic for matching packages to repositories. I think claircore would need to interrogate dnf/yum databases to get this information.

[iainduncani]

We'd also seen this article about determining the CPE for a package but installing packages from the EUS stream did not appear to alter the /root/buildinfo/content_manifests, if something was added to alter those files would Clair pick it up?

[hdonnay]

Maybe? But those files are put there by the Red Hat build system, so putting something there in a "downstream" build would be contra the intended use.

[p-rog]

The crucial step in the rpm fixes identification is finding the package source repository. Knowing the repository for the particular rpm package you can use the repository-to-cpe to find the unique product CPE that later use it as a search key in the Red Hat Security Data. If you use for example Red Hat OVAL, knowing the repository name and CPE give you necessary information to select the right OVAL file. If you use EUS repository then you should use OVAL for EUS stream, not the default OVAL RHEL stream.

I thought that claircode does this repository and CPE detection already in the right way. It's really interesting that in this example CVE (CVE-2022-0778) an incorrect fix has been detected.

[hdonnay]

Rpm doesn't take note of this information. So, as I said, there's a heuristic there.

[hdonnay]

See also PROJQUAY-5185.

[bainsy88]

@hdonnay I've just got round to testing your WIP code against a layer from the image in my original post and it finds the correct repo-id for the package 🎉

openssl 1:1.1.1g-16.el8_4
&{ID: Name:openssl Version:1:1.1.1g-16.el8_4 Kind:binary Source:0x1400099e208 PackageDB:bdb:var/lib/rpm RepositoryHint:hash=sha256%3Af44890b7389a81c36ce5fe50c651867843f9a29e6daa1dd665a4e52d042f2bce&key=199e2f91fd431d51&repoid=rhel-8-for-x86_64-baseos-eus-rpms NormalizedVersion:{Kind: V:[0 0 0 0 0 0 0 0 0 0]} Module: Arch:x86_64 CPE:cpe:2.3:*:*:*:*:*:*:*:*:*:*:*}

Key field being RepositoryHint:hash=sha256%3Af44890b7389a81c36ce5fe50c651867843f9a29e6daa1dd665a4e52d042f2bce&key=199e2f91fd431d51&repoid=rhel-8-for-x86_64-baseos-eus-rpms

[hdonnay]

Thank you so much for doing that. That's very heartening, I'll keep plugging away at it.