Twistlock Reporting CVE's

[dpericaxon]

Proposal

Hello! Our twistlock scan is reporting these CVE's, can this be remediated by switching busybox version?

Repository	Tag	Distro	CVE ID	Type	Packages	Source Package	Package Version	Package License	Fix Status	Description
quay.io/prometheus/prometheus	v2.42.0	BusyBox-1.36.0	PRISMA-2022-0227	go	github.com/emicklei/go-restful/v3		v3.9.0		fixed in v3.10.0	github.com/emicklei/go-restful/v3 module prior to v3.10.0 is vulnerable to Authentication Bypass by Primary Weakness. There is an inconsistency in how go-restful parses URL paths. This inconsistency could lead to several security check bypass in a complex system.
quay.io/prometheus/prometheus	v2.42.0	BusyBox-1.36.0	PRISMA-2022-0270	go	github.com/golang-jwt/jwt/v4		v4.2.0		fixed in v4.4.3	github.com/golang-jwt/jwt/v4 module prior to v4.4.3 is vulnerable to Denial of Service (DoS). In case one of the RegisteredClaims params is empty it can lead to panic.
quay.io/prometheus/prometheus	v2.42.0	BusyBox-1.36.0	CVE-2022-41723	go	golang.org/x/net		v0.5.0		fixed in 0.7.0	A maliciously crafted HTTP/2 stream could cause excessive CPU consumption in the HPACK decoder, sufficient to cause a denial of service from a small number of small requests.
quay.io/prometheus/prometheus	v2.42.0	BusyBox-1.36.0	CVE-2022-41724	binary	go		1.19.5		fixed in 1.19.6	Large handshake records may cause panics in crypto/tls. Both clients and servers may send large TLS handshake records which cause servers and clients, respectively, to panic when attempting to construct responses. This affects all TLS 1.3 clients, TLS 1.2 clients which explicitly enable session resumption (by setting Config.ClientSessionCache to a non-nil value), and TLS 1.3 servers which request client certificates (by setting Config.ClientAuth >= RequestClientCert).
quay.io/prometheus/prometheus	v2.42.0	BusyBox-1.36.0	CVE-2022-41725	binary	go		1.19.5		fixed in 1.19.6	A denial of service is possible from excessive resource consumption in net/http and mime/multipart. Multipart form parsing with mime/multipart.Reader.ReadForm can consume largely unlimited amounts of memory and disk files. This also affects form parsing in the net/http package with the Request methods FormFile, FormValue, ParseMultipartForm, and PostFormValue. ReadForm takes a maxMemory parameter, and is documented as storing "up to maxMemory bytes +10MB (reserved for non-file parts) in memory". File parts which cannot be stored in memory are stored on disk in temporary files. The unconfigurable 10MB reserved for non-file parts is excessively large and can potentially open a denial of service vector on its own. However, ReadForm did not properly account for all memory consumed by a parsed form, such as map entry overhead, part names, and MIME headers, permitting a maliciously crafted form to consume well over 10MB. In addition, ReadForm contained no limit on the number of disk files created, permitting a relatively small request body to create a large number of disk temporary files. With fix, ReadForm now properly accounts for various forms of memory overhead, and should now stay within its documented limit of 10MB + maxMemory bytes of memory consumption. Users should still be aware that this limit is high and may still be hazardous. In addition, ReadForm now creates at most on
quay.io/prometheus/prometheus	v2.42.0	BusyBox-1.36.0	CVE-2022-41723	binary	go		1.19.5		fixed in 1.19.6	A maliciously crafted HTTP/2 stream could cause excessive CPU consumption in the HPACK decoder, sufficient to cause a denial of service from a small number of small requests.
quay.io/prometheus/prometheus	v2.42.0	BusyBox-1.36.0	CVE-2023-24532	binary	go		1.19.5		fixed in 1.20.2, 1.19.7	The ScalarMult and ScalarBaseMult methods of the P256 Curve may return an incorrect result if called with some specific unreduced scalars (a scalar larger than the order of the curve). This does not impact usages of crypto/ecdsa or crypto/ecdh.

[gizmo-rt]

Fixed in v2.43.0

[dpericaxon]

Hey it looks like PRISMA-2023-0046 is the other Go CVE we see with package: github.com/go-resty/resty/v2 v2.7.0

[dgl]

Please see https://prometheus.io/docs/operating/security/#automated-security-scanners -- scanners are a tool, their output is usually not useful, in fact for this we have no way to know what "PRISMA-2023-0046" even is, as that seems to be specific to your scanning tool (kind of defeating the purpose of CVE IDs). Prometheus keeps its dependencies as up-to-date as possible, but dependencies brought in by Prometheus may not do this.

From a quick look I can't see how this would affect Prometheus. If you believe this issue affects Prometheus, please privately submit a security bug per the instructions on the security page.