Description of Problem
I have an image that I know contains a version of openssh-client
that is vulnerable to CVE-2019-6111 but when I scan it in Clair it does not detect this vulnerability. Having dug into the problem I think there are two issues, firstly the packages in any layers other than the base are not detected, secondly when a package is a binary package it is not matched to its source. More details on both of these below.
Problem 1: Non-base layers not scanned
Problem description
I have the following dockerfile that installs a vulnerable version of openssh-client
:
FROM debian:stretch-slim
RUN echo 'deb http://snapshot.debian.org/archive/debian/20170625T040030Z stretch-proposed-updates main' >> /etc/apt/sources.list && \
apt-get -o Acquire::Check-Valid-Until=false update && \
apt-get install openssh-client=1:7.4p1-10+deb9u1 -y
Expected Outcome
I expect to see the openssh-client
listed in the list of installed packages and it to be vulnerable.
Actual Outcome
openssh-client
does not appear in the list of installed packages. I looked at what is in the database and see that the layer does exist for the manifest as:
SELECT COUNT(DISTINCT layer_id) FROM manifest_layer ml
INNER JOIN manifest m
ON m.id=ml.manifest_id
WHERE m.hash='<HASH>'
Returns 2
layers as expected, however, no packages are loaded from the second layer (that contains the openssh-client
as the following only returns 1
:
SELECT COUNT(DISTINCT psa.layer_id) FROM package p
INNER JOIN package_scanartifact psa
ON psa.package_id=p.id
INNER JOIN manifest_layer ml
ON ml.layer_id=psa.layer_id
INNER JOIN manifest m
ON m.id=ml.manifest_id
WHERE m.hash='<HASH>'
When looking at the logs I see a debug message come out saying:
didn't find an os-release or lsb release file
So I wonder if it is not scanning the extra layer because it does not have the base OS files, although I have not taken this investigation further.
Problem 2: Binary packages are not matched to source vulnerabilities
Problem description
To continue my investigation I then squashed the image into a single layer with this Dockerfile:
FROM debian:stretch-slim as base
RUN echo 'deb http://snapshot.debian.org/archive/debian/20170625T040030Z stretch-proposed-updates main' >> /etc/apt/sources.list && \
apt-get -o Acquire::Check-Valid-Until=false update && \
apt-get install openssh-client=1:7.4p1-10+deb9u1 -y
FROM scratch
COPY --from=base / /
Expected Outcome
I expect to see the openssh-client
listed in the list of installed packages and it to be vulnerable.
Actual Outcome
openssh-client
now appeared in the list of installed packages but it was not vulnerable. The vulnerability report now contains the fact that the package is installed:
"172": {
"id": "172",
"name": "openssh-client",
"version": "1:7.4p1-10+deb9u1",
"kind": "binary",
"source": {
"id": "171",
"name": "openssh",
"version": "1:7.4p1-10+deb9u1",
"kind": "source",
"normalized_version": "",
"cpe": ""
},
"normalized_version": "",
"arch": "amd64",
"cpe": ""
}
Again I went to the database to try to figure out why this might not be vulnerable and see that the database only contains data about the binary vulnerabilities:
SELECT COUNT(id) FROM vuln
WHERE dist_id = 'debian' AND package_kind <> 'binary'
Returns 0
. Looking at what it has loaded for CVE-2019-6111
I ran:
SELECT * FROM vuln
WHERE dist_id = 'debian' AND name = 'CVE-2019-6111'
Which returns two results, both with a package_name
of openssh
, i.e. the source package but the package_kind
is binary
in both cases. As I only have the openssh_client
package installed and not the openssh
package I think this is why it is not matching.
Environment
- Clair version/image: I ran:
$ git checkout v4.0.5
$ make local-dev-up-with-quay
- Clair client name/version: I accessed the API via curl
- Host OS: macos using docker
- Kernel (e.g.
uname -a
): Darwin Kernel Version 20.4.0
- Kubernetes version (use
kubectl version
): n/a
- Network/Firewall setup: All on localhost