cortexproject / cortex

A horizontally scalable, highly available, multi-tenant, long term Prometheus.
https://cortexmetrics.io/
Apache License 2.0
5.44k stars 789 forks source link

Cortex v1.14.1 CVE's #5155

Closed dpericaxon closed 1 year ago

dpericaxon commented 1 year ago

Summary

We ran a twistlock scan and returned the following results:

Repository Tag Distro CVE ID Type Packages Source Package Package Version Package License Fix Status Description
quay.io/cortexproject/cortex v1.14.1 alpine-3.14.8 CVE-2022-4304 OS libssl1.1,libcrypto1.1 openssl 1.1.1q-r0 OpenSSL fixed in 1.1.1t-r0 A timing based side channel exists in the OpenSSL RSA Decryption implementation which could be sufficient to recover a plaintext across a network in a Bleichenbacher style attack. To achieve a successful decryption an attacker would have to be able to send a very large number of trial messages for decryption. The vulnerability affects all RSA padding modes: PKCS#1 v1.5, RSA-OEAP and RSASVE. For example, in a TLS connection, RSA is commonly used by a client to send an encrypted pre-master secret to the server. An attacker that had observed a genuine connection between a client and a server could use this flaw to send trial messages to the server and record the time taken to process them. After a sufficiently large number of messages the attacker could recover the pre-master secret used for the original connection and thus be able to decrypt the application data sent over that connection.
quay.io/cortexproject/cortex v1.14.1 alpine-3.14.8 CVE-2023-0215 OS libssl1.1,libcrypto1.1 openssl 1.1.1q-r0 OpenSSL fixed in 1.1.1t-r0 The public API function BIO_new_NDEF is a helper function used for streaming ASN.1 data via a BIO. It is primarily used internally to OpenSSL to support the SMIME, CMS and PKCS7 streaming capabilities, but may also be called directly by end user applications. The function receives a BIO from the caller, prepends a new BIO_f_asn1 filter BIO onto the front of it to form a BIO chain, and then returns the new head of the BIO chain to the caller. Under certain conditions, for example if a CMS recipient public key is invalid, the new filter BIO is freed and the function returns a NULL result indicating a failure. However, in this case, the BIO chain is not properly cleaned up and the BIO passed by the caller still retains internal pointers to the previously freed filter BIO. If the caller then goes on to call BIO_pop() on the BIO then a use-after-free will occur. This will most likely result in a crash. This scenario occurs directly in the internal function B64_write_ASN1() which may cause BIO_new_NDEF() to be called and will subsequently call BIO_pop() on the BIO. This internal function is in turn called by the public API functions PEM_write_bio_ASN1_stream, PEM_write_bio_CMS_stream, PEM_write_bio_PKCS7_stream, SMIME_write_ASN1, SMIME_write_CMS and SMIME_write_PKCS7. Other public API functions that may be impacted by this include i2d_ASN1_bio_stream, BIO_new_CMS, BIO_newPKCS7, i2d
quay.io/cortexproject/cortex v1.14.1 alpine-3.14.8 CVE-2023-0286 OS libssl1.1,libcrypto1.1 openssl 1.1.1q-r0 OpenSSL fixed in 1.1.1t-r0 There is a type confusion vulnerability relating to X.400 address processing inside an X.509 GeneralName. X.400 addresses were parsed as an ASN1_STRING but the public structure definition for GENERAL_NAME incorrectly specified the type of the x400Address field as ASN1_TYPE. This field is subsequently interpreted by the OpenSSL function GENERAL_NAME_cmp as an ASN1_TYPE rather than an ASN1_STRING. When CRL checking is enabled (i.e. the application sets the X509_V_FLAG_CRL_CHECK flag), this vulnerability may allow an attacker to pass arbitrary pointers to a memcmp call, enabling them to read memory contents or enact a denial of service. In most cases, the attack requires the attacker to provide both the certificate chain and CRL, neither of which need to have a valid signature. If the attacker only controls one of these inputs, the other input must already contain an X.400 address as a CRL distribution point, which is uncommon. As such, this vulnerability is most likely to only affect applications which have implemented their own functionality for retrieving CRLs over a network.
quay.io/cortexproject/cortex v1.14.1 alpine-3.14.8 CVE-2022-4450 OS libssl1.1,libcrypto1.1 openssl 1.1.1q-r0 OpenSSL fixed in 1.1.1t-r0 The function PEM_read_bio_ex() reads a PEM file from a BIO and parses and decodes the \"name\" (e.g. \"CERTIFICATE\"), any header data and the payload data. If the function succeeds then the \"name_out\", \"header\" and \"data\" arguments are populated with pointers to buffers containing the relevant decoded data. The caller is responsible for freeing those buffers. It is possible to construct a PEM file that results in 0 bytes of payload data. In this case PEM_read_bio_ex() will return a failure code but will populate the header argument with a pointer to a buffer that has already been freed. If the caller also frees this buffer then a double free will occur. This will most likely lead to a crash. This could be exploited by an attacker who has the ability to supply malicious PEM files for parsing to achieve a denial of service attack. The functions PEM_read_bio() and PEM_read() are simple wrappers around PEM_read_bio_ex() and therefore these functions are also directly affected. These functions are also called indirectly by a number of other OpenSSL functions including PEM_X509_INFO_read_bio_ex() and SSL_CTX_use_serverinfo_file() which are also vulnerable. Some OpenSSL internal uses of these functions are not vulnerable because the caller does not free the header argument if PEM_read_bio_ex() returns a failure code. These locations include the PEM_read_bio_TYPE() functions as well as th
quay.io/cortexproject/cortex v1.14.1 alpine-3.14.8 CVE-2022-46146 go github.com/prometheus/exporter-toolkit v0.7.1 fixed in 0.8.2, 0.7.3 Prometheus Exporter Toolkit is a utility package to build exporters. Prior to versions 0.7.2 and 0.8.2, if someone has access to a Prometheus web.yml file and users\' bcrypted passwords, they can bypass security by poisoning the built-in authentication cache. Versions 0.7.2 and 0.8.2 contain a fix for the issue. There is no workaround, but attacker must have access to the hashed password to use this functionality.
quay.io/cortexproject/cortex v1.14.1 alpine-3.14.8 CVE-2022-41717 go golang.org/x/net/http2 v0.0.0-20220920203100-d0c6ba3f52d9 fixed in 0.4.0 An attacker can cause excessive memory growth in a Go server accepting HTTP/2 requests. HTTP/2 server connections contain a cache of HTTP header keys sent by the client. While the total number of entries in this cache is capped, an attacker sending very large keys can cause the server to allocate approximately 64 MiB per open connection.
quay.io/cortexproject/cortex v1.14.1 alpine-3.14.8 CVE-2021-42373 binary busybox 1.33.1 GPL-2.0-only fixed in 1.33.2 A NULL pointer dereference in Busybox\'s man applet leads to denial of service when a section name is supplied but no page argument is given
quay.io/cortexproject/cortex v1.14.1 alpine-3.14.8 CVE-2021-42377 binary busybox 1.33.1 GPL-2.0-only fixed in 1.33.2 An attacker-controlled pointer free in Busybox\'s hush applet leads to denial of service and possible code execution when processing a crafted shell command, due to the shell mishandling the &&& string. This may be used for remote code execution under rare conditions of filtered command input.
quay.io/cortexproject/cortex v1.14.1 alpine-3.14.8 CVE-2022-41717 binary go 1.19 fixed in 1.19.4, 1.18.9 An attacker can cause excessive memory growth in a Go server accepting HTTP/2 requests. HTTP/2 server connections contain a cache of HTTP header keys sent by the client. While the total number of entries in this cache is capped, an attacker sending very large keys can cause the server to allocate approximately 64 MiB per open connection.
quay.io/cortexproject/cortex v1.14.1 alpine-3.14.8 CVE-2022-41716 binary go 1.19 fixed in 1.19.3, 1.18.8 Due to unsanitized NUL values, attackers may be able to maliciously set environment variables on Windows. In syscall.StartProcess and os/exec.Cmd, invalid environment variable values containing NUL values are not properly checked for. A malicious environment variable value can exploit this behavior to set a value for a different environment variable. For example, the environment variable string \"A=B\x00C=D\" sets the variables \"A=B\" and \"C=D\".
quay.io/cortexproject/cortex v1.14.1 alpine-3.14.8 CVE-2022-32190 binary go 1.19 fixed in 1.18.6 JoinPath and URL.JoinPath do not remove ../ path elements appended to a relative path. For example, JoinPath(\"https://go.dev\", \"../go\") returns the URL \"https://go.dev/../go\", despite the JoinPath documentation stating that ../ path elements are removed from the result.
quay.io/cortexproject/cortex v1.14.1 alpine-3.14.8 CVE-2022-2880 binary go 1.19 fixed in 1.19.2, 1.18.7 Requests forwarded by ReverseProxy include the raw query parameters from the inbound request, including unparseable parameters rejected by net/http. This could permit query parameter smuggling when a Go proxy forwards a parameter with an unparseable value. After fix, ReverseProxy sanitizes the query parameters in the forwarded query when the outbound request\'s Form field is set after the ReverseProxy. Director function returns, indicating that the proxy has parsed the query parameters. Proxies which do not parse query parameters continue to forward the original query parameters unchanged.
quay.io/cortexproject/cortex v1.14.1 alpine-3.14.8 CVE-2022-41715 binary go 1.19 fixed in 1.19.2, 1.18.7 Programs which compile regular expressions from untrusted sources may be vulnerable to memory exhaustion or denial of service. The parsed regexp representation is linear in the size of the input, but in some cases the constant factor can be as high as 40,000, making relatively small regexps consume much larger amounts of memory. After fix, each regexp being parsed is limited to a 256 MB memory footprint. Regular expressions whose representation would use more space than that are rejected. Normal use of regular expressions is unaffected.
quay.io/cortexproject/cortex v1.14.1 alpine-3.14.8 CVE-2022-2879 binary go 1.19 fixed in 1.19.2, 1.18.7 Reader.Read does not set a limit on the maximum size of file headers. A maliciously crafted archive could cause Read to allocate unbounded amounts of memory, potentially causing resource exhaustion or panics. After fix, Reader.Read limits the maximum size of header blocks to 1 MiB.
quay.io/cortexproject/cortex v1.14.1 alpine-3.14.8 CVE-2022-27664 binary go 1.19 fixed in 1.19.1, 1.18.6 In net/http in Go before 1.18.6 and 1.19.x before 1.19.1, attackers can cause a denial of service because an HTTP/2 connection can hang during closing if shutdown were preempted by a fatal error.
quay.io/cortexproject/cortex v1.14.1 alpine-3.14.8 Image should be created with a non-root user cri Image should be created with a non-root user
quay.io/cortexproject/cortex v1.14.1 alpine-3.14.8 CVE-2021-42383 binary busybox 1.33.1 GPL-2.0-only fixed in 1.33.2

We were wondering if there is a timeline to fix these? I see an issue open for updating Go https://github.com/cortexproject/cortex/issues/5147

alanprot commented 1 year ago

We've already updated the alpine to 3.17.

Can you run these on the latest image? Ex: master-74d33df ?

If so we can release 1.14.2 with this new alpine i guess..

dpericaxon commented 1 year ago

@alanprot I could do that but I'm worried if those were built off of master that there are a decent amount of commits since Dec 18th. Is this an invalid concern?

jeromeinsf commented 1 year ago

@dpericaxon master should be fine

jeromeinsf commented 1 year ago

@dpericaxon there is a release candidate to run against now: https://github.com/cortexproject/cortex/releases/tag/v1.15.0-rc.0

friedrichg commented 1 year ago

closing as v1.15.0 has been released. We should automate this more as there will be additional CVEs.