Skip to content

HTTP/2 HPACK, and HTTP/3 QPACK integer overflow and buffer allocation

High
jmcc0nn3ll published GHSA-wgh7-54f2-x98r Oct 10, 2023

Package

maven org.eclipse.jetty.http2:http2-hpack (Maven)

Affected versions

>= 10.0.0, <=10.0.15
>= 11.0.0, <= 11.0.15
>= 9.3.0, <= 9.4.52

Patched versions

10.0.16
11.0.16
9.4.53
maven org.eclipse.jetty.http3:http3-qpack (Maven)
>= 10.0.0, <= 10.0.15
>= 11.0.0, <= 11.0.15
10.0.16
11.0.16

Description

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:

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:

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:

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

Severity

High

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

CVE ID

CVE-2023-36478

Credits