Major For the same image registry.redhat.io/rhel8/redis-5:latest the two versions of Clair in one of our client's deployments report different results:
- production (3.5.1): shows the image as passed
- dev (3.5.6): shows the image as having 1 CVE: CVE-2020-26137
Both databases were updated today, but they still show different results. I tried to replicate the issue they are seeing and created two separate dbs, one for each Clair deployment. In my case, both Clair versions show the CVE for that particular image in my Quay deployment.
I dumped the update_operation table for both Clair deployments, results are attached to the case. From there, it seems to me that both Clair deployments were updated today.
Furthermore, I asked the client to dump the CVE info for that particular CVE and it seems that the info about this CVE was grabbed from the Debian database, this is the output:
id|hash_kind|hash|updater|name|description|issued|links|severity|normalized_severity|package_name|package_version|package_module|package_arch|package_kind|dist_id|dist_name|dist_version|dist_version_code_name|dist_version_id|dist_arch|dist_cpe|dist_pretty_name|repo_name|repo_key|repo_uri|fixed_in_version|arch_operation|vulnerable_range|version_kind 109928|md5|\xc3447eede7cea355856ede7a8cec1f9c|debian-buster-updater|CVE-2020-26137|urllib3 before 1.25.9 allows CRLF injection if the attacker controls the HTTP request method, as demonstrated by inserting CR and LF control characters in the first argument of putrequest(). NOTE: this is similar to CVE-2020-26116.|0001-01-01 00:00:00+00|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-26137||Unknown|python-urllib3||||binary|debian|Debian GNU/Linux|10 (buster)|buster|10|||Debian GNU/Linux 10 (buster)||||0:0|invalid|empty| 123161|md5|\x4b7c8d2ab1caf4bbf915ff2f829b926d|debian-stretch-updater|CVE-2020-26137|urllib3 before 1.25.9 allows CRLF injection if the attacker controls the HTTP request method, as demonstrated by inserting CR and LF control characters in the first argument of putrequest(). NOTE: this is similar to CVE-2020-26116.|0001-01-01 00:00:00+00|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-26137||Unknown|python-urllib3||||binary|debian|Debian GNU/Linux|9 (stretch)|stretch|9|||Debian GNU/Linux 9 (stretch)||||0:1.19.1-1+deb9u1|invalid|empty| (2 rows)
RHEL errata for this CVE: https://access.redhat.com/errata/RHSA-2021:1631
It clearly shows that this particular CVE was fixed in python3-urllib3-1.24.2-5.el8.noarch.rpm package and this package is part of the Redis image:
# podman run --rm -it --entrypoint /bin/bash registry.redhat.io/rhel8/redis-5
bash-4.4$ rpm -qa | grep -i urllib
python3-urllib3-1.24.2-5.el8.noarch
So this is a false positive in this case. Questions:
1) Why are two Clair versions in the customer's environment showing different results for the same image?
2) Why is Clair returning a CVE from a completely different base OS for an image that is not at all vulnerable for that CVE?
