CVE-2023-40225 (published 2023-08-10T21:15Z)

HAProxy through 2.0.32, 2.1.x and 2.2.x through 2.2.30, 2.3.x and 2.4.x through 2.4.23, 2.5.x and 2.6.x before 2.6.15, 2.7.x before 2.7.10, and 2.8.x before 2.8.2 forwards empty Content-Length headers, violating RFC 9110 section 8.6. In uncommon cases, an HTTP/1 server behind HAProxy may interpret the payload as an extra request.

CVSS v3 base score: 7.2, HIGH (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N)

Weakness information:
cwe_id: CWE-444
cwe_name: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')
description: The product acts as an intermediary HTTP agent
         (such as a proxy or firewall) in the data flow between two
         entities such as a client and server, but it does not
         interpret malformed HTTP requests or responses in ways that
         are consistent with how the messages will be processed by
         those entities that are at the ultimate destination.
extended_description: 
	   HTTP requests or responses ("messages") can be
	   malformed or unexpected in ways that cause web servers or
	   clients to interpret the messages in different ways than
	   intermediary HTTP agents such as load balancers, reverse
	   proxies, web caching proxies, application firewalls,
	   etc. For example, an adversary may be able to add duplicate
	   or different header fields that a client or server might
	   interpret as one set of messages, whereas the intermediary
	   might interpret the same sequence of bytes as a different
	   set of messages. For example, discrepancies can arise in
	   how to handle duplicate headers like two Transfer-encoding
	   (TE) or two Content-length (CL), or the malicious HTTP
	   message will have different headers for TE and
	   CL.
	   The inconsistent parsing and interpretation of messages
	   can allow the adversary to "smuggle" a message to the
	   client/server without the intermediary being aware of it.
	   This weakness is usually the result of the usage
	   of outdated or incompatible HTTP protocol versions in the
	   HTTP agents.
         
         

Fix information:
repo_url: https://github.com/haproxy/haproxy
commit_details: repo_url: https://github.com/haproxy/haproxy
author: Willy Tarreau
author_date: 2023-08-09 08:32:48+02:00
msg: BUG/MAJOR: http: reject any empty content-length header value

The content-length header parser has its dedicated function, in order
to take extreme care about invalid, unparsable, or conflicting values.
But there's a corner case in it, by which it stops comparing values
when reaching the end of the header. This has for a side effect that
an empty value or a value that ends with a comma does not deserve
further analysis, and it acts as if the header was absent.

While this is not necessarily a problem for the value ending with a
comma as it will be cause a header folding and will disappear, it is a
problem for the first isolated empty header because this one will not
be recontructed when next ones are seen, and will be passed as-is to the
backend server. A vulnerable HTTP/1 server hosted behind haproxy that
would just use this first value as "0" and ignore the valid one would
then not be protected by haproxy and could be attacked this way, taking
the payload for an extra request.

In field the risk depends on the server. Most commonly used servers
already have safe content-length parsers, but users relying on haproxy
to protect a known-vulnerable server might be at risk (and the risk of
a bug even in a reputable server should never be dismissed).

A configuration-based work-around consists in adding the following rule
in the frontend, to explicitly reject requests featuring an empty
content-length header that would have not be folded into an existing
one:

    http-request deny if { hdr_len(content-length) 0 }

The real fix consists in adjusting the parser so that it always expects a
value at the beginning of the header or after a comma. It will now reject
requests and responses having empty values anywhere in the C-L header.

This needs to be backported to all supported versions. Note that the
modification was made to functions h1_parse_cont_len_header() and
http_parse_cont_len_header(). Prior to 2.8 the latter was in
h2_parse_cont_len_header(). One day the two should be refused but the
former is also used by Lua.

The HTTP messaging reg-tests were completed to test these cases.

Thanks to Ben Kallus of Dartmouth College and Narf Industries for
reporting this! (this is in GH #2237).
repository: repo_url: https://github.com/haproxy/haproxy
repo_name: haproxy/haproxy
description: HAProxy Load Balancer's development branch (mirror of git.haproxy.org)
repo_language: C
owner: haproxy
file_changes: filename: h1_to_h1.vtc
change_type: ModificationType.MODIFY
diff: @@ -273,3 +273,29 @@ client c3h1 -connect ${h1_feh1_sock} {
 	# arrive here.
 	expect_close
 } -run
+
+client c4h1 -connect ${h1_feh1_sock} {
+	# this request is invalid and advertises an invalid C-L ending with an
+        # empty value, which results in a stream error.
+	txreq \
+	  -req "GET" \
+	  -url "/test31.html" \
+          -hdr "content-length: 0," \
+          -hdr "connection: close"
+	rxresp
+	expect resp.status == 400
+	expect_close
+} -run
+
+client c5h1 -connect ${h1_feh1_sock} {
+	# this request is invalid and advertises an empty C-L, which results
+	# in a stream error.
+	txreq \
+	  -req "GET" \
+	  -url "/test41.html" \
+          -hdr "content-length:" \
+          -hdr "connection: close"
+	rxresp
+	expect resp.status == 400
+	expect_close
+} -run

programming_language: CoffeeScript
filename: h2_to_h1.vtc
change_type: ModificationType.MODIFY
diff: @@ -9,6 +9,8 @@ barrier b1 cond 2 -cyclic
 barrier b2 cond 2 -cyclic
 barrier b3 cond 2 -cyclic
 barrier b4 cond 2 -cyclic
+barrier b5 cond 2 -cyclic
+barrier b6 cond 2 -cyclic
 
 server s1 {
 	rxreq
@@ -30,6 +32,12 @@ server s1 {
 
 	barrier b4 sync
 	# the next request is never received
+
+	barrier b5 sync
+	# the next request is never received
+
+	barrier b6 sync
+	# the next request is never received
 } -repeat 2 -start
 
 haproxy h1 -conf {
@@ -119,6 +127,32 @@ client c1h2 -connect ${h1_feh2_sock} {
 		txdata -data "this is sent and ignored"
 		rxrst
 	} -run
+
+	# fifth request is invalid and advertises an invalid C-L ending with an
+        # empty value, which results in a stream error.
+	stream 9 {
+		barrier b5 sync
+		txreq \
+		  -req "GET" \
+		  -scheme "https" \
+		  -url "/test5.html" \
+		  -hdr "content-length" "0," \
+		  -nostrend
+		rxrst
+	} -run
+
+	# sixth request is invalid and advertises an empty C-L, which results
+	# in a stream error.
+	stream 11 {
+		barrier b6 sync
+		txreq \
+		  -req "GET" \
+		  -scheme "https" \
+		  -url "/test6.html" \
+		  -hdr "content-length" "" \
+		  -nostrend
+		rxrst
+	} -run
 } -run
 
 # HEAD requests : don't work well yet
@@ -261,4 +295,30 @@ client c3h2 -connect ${h1_feh2_sock} {
 		txdata -data "this is sent and ignored"
 		rxrst
 	} -run
+
+	# fifth request is invalid and advertises invalid C-L ending with an
+        # empty value, which results in a stream error.
+	stream 9 {
+		barrier b5 sync
+		txreq \
+		  -req "POST" \
+		  -scheme "https" \
+		  -url "/test25.html" \
+		  -hdr "content-length" "0," \
+		  -nostrend
+		rxrst
+	} -run
+
+	# sixth request is invalid and advertises an empty C-L, which results
+	# in a stream error.
+	stream 11 {
+		barrier b6 sync
+		txreq \
+		  -req "POST" \
+		  -scheme "https" \
+		  -url "/test26.html" \
+		  -hdr "content-length" "" \
+		  -nostrend
+		rxrst
+	} -run
 } -run

programming_language: Shell
filename: h1.c
change_type: ModificationType.MODIFY
diff: @@ -34,13 +34,20 @@ int h1_parse_cont_len_header(struct h1m *h1m, struct ist *value)
 	int not_first = !!(h1m->flags & H1_MF_CLEN);
 	struct ist word;
 
-	word.ptr = value->ptr - 1; // -1 for next loop's pre-increment
+	word.ptr = value->ptr;
 	e = value->ptr + value->len;
 
-	while (++word.ptr < e) {
+	while (1) {
+		if (word.ptr >= e) {
+			/* empty header or empty value */
+			goto fail;
+		}
+
 		/* skip leading delimiter and blanks */
-		if (unlikely(HTTP_IS_LWS(*word.ptr)))
+		if (unlikely(HTTP_IS_LWS(*word.ptr))) {
+			word.ptr++;
 			continue;
+		}
 
 		/* digits only now */
 		for (cl = 0, n = word.ptr; n < e; n++) {
@@ -79,6 +86,13 @@ int h1_parse_cont_len_header(struct h1m *h1m, struct ist *value)
 		h1m->flags |= H1_MF_CLEN;
 		h1m->curr_len = h1m->body_len = cl;
 		*value = word;
+
+		/* Now either n==e and we're done, or n points to the comma,
+		 * and we skip it and continue.
+		 */
+		if (n++ == e)
+			break;
+
 		word.ptr = n;
 	}
 	/* here we've reached the end with a single value or a series of

programming_language: C
filename: http.c
change_type: ModificationType.MODIFY
diff: @@ -707,13 +707,20 @@ int http_parse_cont_len_header(struct ist *value, unsigned long long *body_len,
 	struct ist word;
 	int check_prev = not_first;
 
-	word.ptr = value->ptr - 1; // -1 for next loop's pre-increment
+	word.ptr = value->ptr;
 	e = value->ptr + value->len;
 
-	while (++word.ptr < e) {
+	while (1) {
+		if (word.ptr >= e) {
+			/* empty header or empty value */
+			goto fail;
+		}
+
 		/* skip leading delimiter and blanks */
-		if (unlikely(HTTP_IS_LWS(*word.ptr)))
+		if (unlikely(HTTP_IS_LWS(*word.ptr))) {
+			word.ptr++;
 			continue;
+		}
 
 		/* digits only now */
 		for (cl = 0, n = word.ptr; n < e; n++) {
@@ -751,6 +758,13 @@ int http_parse_cont_len_header(struct ist *value, unsigned long long *body_len,
 		/* OK, store this result as the one to be indexed */
 		*body_len = cl;
 		*value = word;
+
+		/* Now either n==e and we're done, or n points to the comma,
+		 * and we skip it and continue.
+		 */
+		if (n++ == e)
+			break;
+
 		word.ptr = n;
 		check_prev = 1;
 	}

programming_language: Ruby