node_exporter
node_exporter copied to clipboard
CVE-2021-28831 on node-exporter:v1.1.2
Hello There, A scan is indicating there is a high vulnerability in the image quay.io/prometheus/node-exporter:v1.1.2, the result is:
+----------------+----------+------+---------+---------+--------+-----------+------------+----------------------------------------------------+
| CVE | SEVERITY | CVSS | PACKAGE | VERSION | STATUS | PUBLISHED | DISCOVERED | DESCRIPTION |
+----------------+----------+------+---------+---------+--------+-----------+------------+----------------------------------------------------+
| CVE-2021-28831 | high | 7.50 | busybox | 1.32.1 | | 69 days | < 1 hour | decompress_gunzip.c in BusyBox through 1.32.1 |
| | | | | | | | | mishandles the error bit on the huft_build |
| | | | | | | | | result pointer, with a resultant invalid free or |
| | | | | | | | | segmentation... |
+----------------+----------+------+---------+---------+--------+-----------+------------+----------------------------------------------------+
I have also scanned node-exporter:master and found that this issue is resolved in that version going forward.
Could we get another release with the updated busybox version?
We'll release a new version soon but this issue isn't really affected the node-exporter since nothing runs busybox or any of it's applets on it's own. So this would only apply to an operator exec'ing into the container and extracting a tarball.
@SuperQ @pgier We might want to re-consider 'FROM scratch' images, if just so we don't have to deal with this kind of stuff. There are ephemeral containers these days that should alleviate the need for busybox in the container: https://kubernetes.io/docs/concepts/workloads/pods/ephemeral-containers/
It is already accepted that we are willing to support distroless containers in addition to busybox containers, and switch to distroless containers by default in the next major release.
Are we working on supporting distroless for node-exporter. I can see current version 1.60 is still running on linux debian distro @roidelapluie
We don't use Debian. The base image is built with some base config files from Debian, but the only binary component is BusyBox
Then, what distro is being used in node-exporter and what does it take to fix vulnerabilities for openssl and libssl.
Then, what distro is being used in node-exporter and what does it take to fix vulnerabilities for openssl and libssl.
@SuperQ : Kind ping.
The node_exporter, like most Prometheus components, use prometheus/busybox as the base layer.
This specific issue is about a vulnerability in a 2+ year old release. There have been several releases since this version that addressed the version of busybox matched by the scanner.
Besides this, there is no actual exploitable path here, since the underlying distribution in the node_exporter is not used as part of the node_exporter itself. This is because the node_exporter is a statically compiled Go binary and does not use any of the executables or libraries contained in the Docker image. The busybox base is simply for convince in debugging.
In order to exploit busybox, you would already need to be inside the container and have privileges to execute anything. So there is no escalation path.
Security scanners reporting this class of problems are a false positives.