Closed huornlmj closed 7 months ago
These are all in Debian Packages with no fixes available so there is nothing for us to update. I trust the Debian Security Team to have provided a fix when the CVE is actually important.
Unfixed packages would often be true in many other distributions (like Ubuntu), but they are more aggressive at marking CVE tracking issues as "won't fix", whereas Debian usually just puts "no-dsa" (which I interpret as, "any Debian Developer could fix this if they want to, but the Debian Security Team considers it low security impact and so won't spend extra time to backport a fix").
Vulnerability tools incorporate the "won't fix" info, so it can look like an Ubuntu based image is "more secure" (it could even be using the exact same underlying package version from Debian). I believe Docker Scout is incorporating some of the Debian "no-dsa" reports into their vulnerability analysis, which is probably why it is lower.
$ docker run -it --rm --user root haproxy bash
Unable to find image 'haproxy:latest' locally
latest: Pulling from library/haproxy
f03b40093957: Pull complete
a3d37cc643bc: Pull complete
70ec3cce8b15: Pull complete
4df0e13bf58b: Pull complete
Digest: sha256:b789b97827c87ba222f6e24073c3796773dd32b8c3cace5c673f10cddeadd1ab
Status: Downloaded newer image for haproxy:latest
root@90e83562b000:/var/lib/haproxy# apt update
Get:1 http://deb.debian.org/debian bullseye InRelease [116 kB]
Get:2 http://deb.debian.org/debian-security bullseye-security InRelease [48.4 kB]
Get:3 http://deb.debian.org/debian bullseye-updates InRelease [44.1 kB]
Get:4 http://deb.debian.org/debian bullseye/main amd64 Packages [8183 kB]
Get:5 http://deb.debian.org/debian-security bullseye-security/main amd64 Packages [245 kB]
Get:6 http://deb.debian.org/debian bullseye-updates/main amd64 Packages [14.8 kB]
Fetched 8651 kB in 1s (8187 kB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.
root@90e83562b000:/var/lib/haproxy#
Official Images FAQ:
Though not every CVE is removed from the images, we take CVEs seriously and try to ensure that images contain the most up-to-date packages available within a reasonable time frame
Also stuff like “e2fsprogs” is effectively never used from within a container. If the code isn't executed the vulnerability is much much less relevant. HAProxy tries to make it hard to exploit code execution vulnerabilities, e.g. by setting an ulimit that prevents spawning additional processes:
https://docs.haproxy.org/dev/configuration.html#insecure-fork-wanted
thanks @huornlmj for raising this.
As @yosifkit mentioned, Docker Scout incorporates vendor/distribution specific advisory data (in this case reports by the Debian security team). Take a look at CVE-2019-8457: The Debian security team assigned no-dsa
to this at https://nvd.nist.gov/vuln/detail/CVE-2019-8457 which effectively means that this isn't a security concern on Debian. That's why that CVE doesn't show up in our reports; Trivy on the other hand seems to prefer the NIST data and assign a critical severity to this CVE.
We understand that this has the potential for misinterpretation and we are working on surfacing this information more clearly to users.
Hi. While Docker's Scout vulnerability scanning engine only sees 24 low severity issues, when compared to Trivy in image scanning mode, it finds many many more:
I don't see any scanning in the workflows, so my proposition would be to begin using Trivy so that end users can avoid running containerized HAproxy with so many vulnerabilities.
Full report: