An integer overflow in MetaDataBuilder.checkSize allows for HTTP/2 HPACK header values to exceed their size limit.

In MetaDataBuilder.java, the following code determines if a header name or value exceeds the size limit, and throws an exception if the limit is exceeded:

java 291 public void checkSize(int length, boolean huffman) throws SessionException 292 { 293 // Apply a huffman fudge factor 294 if (huffman) 295 length = (length 4) / 3; 296 if ((size + length) > maxSize) 297 throw new HpackException.SessionException("Header too large %d > %d", size + length, maxSize); 298 }

However, when length is very large and huffman is true, the multiplication by 4 in line 295 will overflow, and length will become negative. (size+length) will now be negative, and the check on line 296 will not be triggered.

Furthermore, MetaDataBuilder.checkSize allows for user-entered HPACK header value sizes to be negative, potentially leading to a very large buffer allocation later on when the user-entered size is multiplied by 2.

In MetaDataBuilder.java, the following code determines if a header name or value exceeds the size limit, and throws an exception if the limit is exceeded:

java public void checkSize(int length, boolean huffman) throws SessionException { // Apply a huffman fudge factor if (huffman) length = (length 4) / 3; if ((size + length) > maxSize) throw new HpackException.SessionException("Header too large %d > %d", size + length, maxSize); }

However, no exception is thrown in the case of a negative size. Later, in Huffman.decode, the user-entered length is multiplied by 2 before allocating a buffer:

java public static String decode(ByteBuffer buffer, int length) throws HpackException.CompressionException { Utf8StringBuilder utf8 = new Utf8StringBuilder(length 2); // ...

This means that if a user provides a negative length value (or, more precisely, a length value which, when multiplied by the 4/3 fudge factor, is negative), and this length value is a very large positive number when multiplied by 2, then the user can cause a very large buffer to be allocated on the server.

Exploit Scenario 1 An attacker repeatedly sends HTTP messages with the HPACK header 0x00ffffffffff02. Each time this header is decoded: + HpackDecode.decode will determine that a Huffman-coded value of length 805306494 needs to be decoded. + MetaDataBuilder.checkSize will approve this length. + Huffman.decode will allocate a 1.6 GB string array. + Huffman.decode will have a buffer overflow error, and the array will be deallocated the next time garbage collection happens. (Note: this can be delayed by appending valid huffman-coded characters to the end of the header.)

Depending on the timing of garbage collection, the number of threads, and the amount of memory available on the server, this may cause the server to run out of memory.

Exploit Scenario 2 An attacker repeatedly sends HTTP messages with the HPACK header 0x00ff8080ffff0b. Each time this header is decoded: + HpackDecode.decode will determine that a Huffman-coded value of length -1073758081 needs to be decoded + MetaDataBuilder.checkSize will approve this length + The number will be multiplied by 2 to get 2147451134, and Huffman.decode will allocate a 2.1 GB string array + Huffman.decode will have a buffer overflow error, and the array will be deallocated the next time garbage collection happens (Note that this deallocation can be delayed by adding valid Huffman-coded characters to the end of the header)

Depending on the timing of garbage collection, the number of threads, and the amount of memory available on the server, this may cause the server to run out of memory.

Impact Users of HTTP/2 can be impacted by a remote denial of service attack.

Patches Fixed in Jetty 10.0.16 and Jetty 11.0.16 Fixed in Jetty 9.4.53 Jetty 12.x is unaffected.

Workarounds No workarounds possible, only patched versions of Jetty.

References https://github.com/eclipse/jetty.project/pull/9634

Impact If an HTTP/2 connection gets TCP congested, when an idle timeout occurs the HTTP/2 session is marked as closed, and then a GOAWAY frame is queued to be written. However it is not written because the connection is TCP congested. When another idle timeout period elapses, it is then supposed to hard close the connection, but it delegates to the HTTP/2 session which reports that it has already been closed so it does not attempt to hard close the connection.

This leaves the connection in ESTABLISHED state (i.e. not closed), TCP congested, and idle.

An attacker can cause many connections to end up in this state, and the server may run out of file descriptors, eventually causing the server to stop accepting new connections from valid clients.

The client may also be impacted (if the server does not read causing a TCP congestion), but the issue is more severe for servers.

Patches Patched versions: 9.4.54 10.0.20 11.0.20 12.0.6

Workarounds Disable HTTP/2 and HTTP/3 support until you can upgrade to a patched version of Jetty. HTTP/1.x is not affected.

References https://github.com/jetty/jetty.project/issues/11256.

Jetty through 9.4.x contains a timing channel attack in util/security/Password.java, which allows attackers to obtain access by observing elapsed times before rejection of incorrect passwords.

Eclipse Jetty is vulnerable to HTTP request smuggling, caused by a flaw when handling more than one Content-Length headers. By sending a specially-crafted request, an attacker could exploit this vulnerability to poison the web cache, bypass web application firewall protection, and conduct XSS attacks.

Eclipse Jetty is vulnerable to HTTP request smuggling, caused by improper handling of Chunked Transfer-Encoding chunk size. By sending a specially-crafted request, an attacker could exploit this vulnerability to poison the web cache, bypass web application firewall protection, and conduct XSS attacks.

Technical Details Below is a technical explanation of a newly discovered vulnerability in HTTP/2, which we refer to as “MadeYouReset.”

MadeYouReset Vulnerability Summary The MadeYouReset DDoS vulnerability is a logical vulnerability in the HTTP/2 protocol, that uses malformed HTTP/2 control frames in order to break the max concurrent streams limit - which results in resource exhaustion and distributed denial of service.

Mechanism The vulnerability uses malformed HTTP/2 control frames, or malformed flow, in order to make the server reset streams created by the client (using the RSTSTREAM frame). The vulnerability could be triggered by several primitives, defined by the RFC of HTTP/2 (RFC 9113). The Primitives are: 1. WINDOWUPDATE frame with an increment of 0 or an increment that makes the window exceed 2^31 - 1. (section 6.9 + 6.9.1) 2. HEADERS or DATA frames sent on a half-closed (remote) stream (which was closed using the ENDSTREAM flag). (note that for some implementations it's possible a CONTINUATION frame to trigger that as well - but it's very rare). (Section 5.1) 3. PRIORITY frame with a length other than 5. (section 6.3) From our experience, the primitives are likely to exist in the decreasing order listed above. Note that based on the implementation of the library, other primitives (which are not defined by the RFC) might exist - meaning scenarios in which RSTSTREAM is not supposed to be sent, but in the implementation it does. On the other hand - some RFC-defined primitives might not work, even though they are defined by the RFC (as some implementations are not fully complying with RFC). For example, some implementations we’ve seen discard the PRIORITY frame - and thus does not return RSTSTREAM, and some implementations send GOAWAY when receiving a WINDOWUPDATE frame with increment of 0.

The vulnerability takes advantage of a design flaw in the HTTP/2 protocol - While HTTP/2 has a limit on the number of concurrently active streams per connection (which is usually 100, and is set by the parameter SETTINGSMAXCONCURRENTSTREAMS), the number of active streams is not counted correctly - when a stream is reset, it is immediately considered not active, and thus unaccounted for in the active streams counter. While the protocol does not count those streams as active, the server’s backend logic still processes and handles the requests that were canceled.

Thus, the attacker can exploit this vulnerability to cause the server to handle an unbounded number of concurrent streams from a client on the same connection. The exploitation is very simple: the client issues a request in a stream, and then sends the control frame that causes the server to send a RSTSTREAM.

Attack Flow For example, a possible attack scenario can be: 1. Attacker opens an HTTP/2 connection to the server. 2. Attacker sends HEADERS frame with ENDSTREAM flag on a new stream X. 3. Attacker sends WINDOWUPDATE for stream X with flow-control window of 0. 4. The server receives the WINDOWUPDATE and immediately sends RSTSTREAM for stream X to the client (+ decreases the active streams counter by 1).

The attacker can repeat steps 2+3 as rapidly as it is capable, since the active streams counter never exceeds 1 and the attacker does not need to wait for the response from the server. This leads to resource exhaustion and distributed denial of service vulnerabilities with an impact of: CPU overload and/or memory exhaustion (implementation dependant)

Comparison to Rapid Reset The vulnerability takes advantage of a design flow in the HTTP/2 protocol that was also used in the Rapid Reset vulnerability (CVE-2023-44487) which was exploited as a zero-day in the wild in August 2023 to October 2023, against multiple services and vendors. The Rapid Reset vulnerability uses RSTSTREAM frames sent from the client, in order to create an unbounded amount of concurrent streams - it was given a CVSS score of 7.5. Rapid Reset was mostly mitigated by limiting the number/rate of RSTSTREAM sent from the client, which does not mitigate the MadeYouReset attack - since it triggers the server to send a RSTSTREAM.

Suggested Mitigations for MadeYouReset A quick and easy mitigation will be to limit the number/rate of RSTSTREAMs sent from the server. It is also possible to limit the number/rate of control frames sent by the client (e.g. WINDOWUPDATE and PRIORITY), and treat protocol flow errors as a connection error.

As mentioned in our previous message, this is a protocol-level vulnerability that affects multiple vendors and implementations. Given its broad impact, it is the shared responsibility of all parties involved to handle the disclosure process carefully and coordinate mitigations effectively.

If you have any questions, we will be happy to clarify or schedule a Zoom call.

Gal, Anat and Yaniv.

Jetty's Team Notes

Impact A denial of service vulnerability similar to Rapid Reset, but where the client triggers a reset from the server by sending a malformed or invalid frame. In particular, this may be triggered by WINDOWUPDATE frames that are invalid (e.g. with delta==0 or when the delta makes the window exceed 2^31-1).

Patches Patch has been merged into 12.0.x mainline via https://github.com/jetty/jetty.project/pull/13449.

Workarounds No workarounds apart disabling HTTP/2.