Trivy: Scanning RHEL/UBI images

[pealtrufo]

Hi,

I am running scans against RedHat UBI image 'ubi8/nodejs-12:1-64', which is currently the latest tag.
https://catalog.redhat.com/software/containers/ubi8/nodejs-12/5d3fff015a13461f5fb8635a?container-tabs=overview

RedHat's security rating is 'A' for this image, and it doesn't seem to highlight any issue with any of the packages.
When I scan this image using Trivy, this is what is reported:

2020-11-12T16:34:11.687Z    INFO    Detecting RHEL/CentOS vulnerabilities...

....../ubi8/nodejs-12:1-64 (redhat 8.3)
============================================================================
Total: 401 (UNKNOWN: 0, LOW: 183, MEDIUM: 199, HIGH: 19, CRITICAL: 0)

If I run the same scan ignoring unfixed vulnerabilities:

2020-11-12T16:36:19.473Z    INFO    Detecting RHEL/CentOS vulnerabilities...

....../ubi8/nodejs-12:1-64 (redhat 8.3)
============================================================================
Total: 14 (UNKNOWN: 0, LOW: 3, MEDIUM: 0, HIGH: 11, CRITICAL: 0)

I am not sure I understand why RedHat classifies this image with an 'A' security rating while Trivy highlights 11 high severity vulnerabilities.

When looking on RedHat's site to one of the High severity CVEs that Trivy highlights, I came across this:
https://access.redhat.com/security/cve/cve-2020-15999

So, I guess the question would be: Is Trivy an OVAL-compatible image scanner?

Thanks

[knqyf263]

@pealtrufo Yes, Trivy is an OVAL-compatible scanner. The following advisory says freetype-2.9.1-4.el8_3.1.x86_64.rpm is the fixed version, but 2.9.1-4.el8 is installed in the image actually.
https://access.redhat.com/errata/RHSA-2020:4952

2.9.1-4.el8 is older than 2.9.1-4.el8_3.1, so this vulnerability is detected. We can confirm it with rpm python package provided by Red Hat.

[root@1f3610ffc868 /]# python
>>> import rpm
>>> from rpmUtils.miscutils import stringToVersion
>>> rpm.labelCompare(stringToVersion("2.9.1-4.el8"), stringToVersion("2.9.1-4.el8_3.1"))
-1

Also, 2.9.1-4.el8 can be updated to 2.9.1-4.el8_3.1. You can see it with yum check-update.

$ docker run --rm -it registry.access.redhat.com/ubi8/nodejs-12 bash
bash-4.4$ rpm -q freetype
freetype-2.9.1-4.el8.x86_64
bash-4.4$ yum check-update freetype
Last metadata expiration check: 0:23:46 ago on Sun Nov 15 16:08:08 2020.

freetype.x86_64                                                                      2.9.1-4.el8_3.1                                                                      ubi-8-baseos

Therefore, if I understand correctly, freetype-2.9.1-4.el8 is vulnerable to CVE-2020-15999 and needs to be updated to freetype-2.9.1-4.el8_3.1 according to RHSA-2020:4952. In short, Trivy's result seems to be correct.

I don't know why RedHat's security rating is 'A'. You can ask Red Hat team why freetype-2.9.1-4.el8 looks vulnerable, but the rating is 'A'.

[knqyf263]

In addition, I tried dnf updateinfo list security on RHEL8 VM and it showed RHSA-2020:4952 as well.

[ec2-user@ip-172-31-47-16 ~]$ rpm -q freetype
freetype-2.9.1-4.el8.x86_64
[ec2-user@ip-172-31-47-16 ~]$ sudo dnf updateinfo list security
Last metadata expiration check: 0:00:34 ago on Sun Nov 15 17:09:02 2020.
RHSA-2020:4952 Important/Sec. freetype-2.9.1-4.el8_3.1.x86_64
RHSA-2020:4685 Important/Sec. kernel-4.18.0-240.1.1.el8_3.x86_64
RHSA-2020:4685 Important/Sec. kernel-core-4.18.0-240.1.1.el8_3.x86_64
RHSA-2020:4685 Important/Sec. kernel-modules-4.18.0-240.1.1.el8_3.x86_64

dnf check-update also displays 2.9.1-4.el8_3.1 is the latest version.

[ec2-user@ip-172-31-47-16 ~]$ sudo dnf check-update freetype
Last metadata expiration check: 0:02:13 ago on Sun Nov 15 17:09:02 2020.

freetype.x86_64                                                                2.9.1-4.el8_3.1                                                                 rhel-8-baseos-rhui-rpms

From these verifications, I think the status of the UBI image is not correct.

[pealtrufo]

Thanks @knqyf263, very useful. I will definitely try to get feedback from RedHat about this.

I have found the below in the meantime, which I am not sure would explain any of this:
https://access.redhat.com/security/updates/backporting
Also they seem to suggest here that these could be false positives when using non OVAL-compliant scanner (although I know you mentioned Trivy understands OVAL feeds): https://access.redhat.com/blogs/766093/posts/2998921

In any case, for this same image, there are these other high severity CVEs also detected by Trivy:

If I run the same yum check-update and dnf check-update for this package, I doesn't seem to get any suggested update. Does that make any sense to you?

Kind regards

[knqyf263]

It is an issue we already know regarding Modularity introduced at RHEL 8. We're trying to fix it now. Thanks.

[knqyf263]

776 works around this issue and it will be included at v0.15.0. Also, we're supporting modular packages shortly. Thank you for the report.

[knqyf263]

https://github.com/aquasecurity/trivy/pull/790 finally addressed this issue.