Triage reported vulnerability discrepancies in Red Hat Containers

Solution Unverified - Updated

Environment

Any Red Hat Enterprise Linux (RHEL) 7 or 8 based container, including Universal Base Image (UBI) containers that deploy non-OS type packages, like java, nodejs, and python.

Issue

Whether or not a third party Vulnerability Scanner is Content from redhat-connect.gitbook.io is not included.certified with Red Hat, scan results may still contain discrepancies and lead to false positives for non-operating system packages like Java JARs, nodejs, and python packages. Third party scanners that have elected not to implement the rpm cli to identify which files originate from Red Hat will not be able to accurately identify RPM files because Red Hat patching versioning information may not be available in the packages themselves.

For example, Java .jars deployed by Red Hat RPMs may not have the correct Red Hat versioning string in the .jar file name or MANIFEST.MF file. Similarly, nodejs packages may not have the correct patched version in their associated package.json file.

Using RPM is the recommended approach to accurately identify if any file in a Red Hat Container has been deployed by an RPM.

Resolution

Customers will need to triage these JARs and other non-OS type packages to verify if they are vulnerable or not (see Diagnostic Steps below).

Root Cause

Java JARs deployed by RPMs in RHEL 7 & 8 based containers do not contain Red Hat patched versioning information in the .jar file name or MANIFEST.MF file.

Diagnostic Steps

NOTE: The following steps provide an example of how to verify if a JAR is managed by Red Hat and help understand the status and severity of the vulnerability reported on the java package. A lot of times, the file path of the .jar file will provide good evidence that it’s part of a Red Hat RPM (i.e. /opt/rh/rh-maven35/root/usr/share/java).

  • Run the container that was analyzed.
$ podman run -it --entrypoint /bin/bash registry.redhat.io/openshift4/ose-jenkins-agent-maven:v4.4
  • If the file path is known, run the rpm command using the whatprovides option.
$ rpm -q --whatprovides /opt/rh/rh-maven35/root/usr/share/java/jackson-databind.jar
  • If the file path is not known, run the rpm command using the qa parameter.
$ rpm -qa | grep dom4j rh-maven35-dom4j-javadoc-2.0.0-1.2.el7.noarch
  • If an RPM was found, run rpm with the ql parameter for that RPM.
$ rpm -ql rh-maven35-dom4j-2.0.0-1.2.el7.noarch
  • Verify the jar is found in the results of the ql command.

At this point, the origin of the JAR should be known, whether it’s managed by Red Hat or not. If managed by Red Hat, the next item to understand is what Red Hat states about the JAR’s vulnerabilities. An important step to make this determination is understanding the Product that deployed the discovered RPM. For example, looking at Red Hat’s CVE pages, different Products are affected differently by vulnerabilities, i.e. https://access.redhat.com/security/cve/CVE-2018-14721.

  • The container has some evidence on which product has been deployed. Run the following commands to find the listed content sets in the container:
$ cd /root/buildinfo/content_manifests
$ cat (all the .json files shown)
SBR
Product(s)
Components
Category
Tags

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.