Skip to content

Integer Overflow in Chunked Transfer-Encoding

Moderate severity GitHub Reviewed Published Jul 7, 2021 in hyperium/hyper • Updated Feb 3, 2023

Package

cargo hyper (Rust)

Affected versions

< 0.14.10

Patched versions

0.14.10

Description

Summary

hyper's HTTP server and client code had a flaw that could trigger an integer overflow when decoding chunk sizes that are too big. This allows possible data loss, or if combined with an upstream HTTP proxy that allows chunk sizes larger than hyper does, can result in "request smuggling" or "desync attacks".

Vulnerability

Example:

GET / HTTP/1.1
Host: example.com
Transfer-Encoding: chunked

f0000000000000003
abc
0

hyper only reads the rightmost 64-bit integer as the chunk size. So it reads f0000000000000003 as 3. A loss of data can occur since hyper would then read only 3 bytes of the body. Additionally, an HTTP request smuggling vulnerability would occur if using a proxy which instead has prefix truncation in the chunk size, or that understands larger than 64-bit chunk sizes.

Read more about desync attacks: https://portswigger.net/research/http-desync-attacks-request-smuggling-reborn

Impact

To determine if vulnerable to data loss, these things must be true:

  • Using HTTP/1.1. Since HTTP/2 does not use chunked encoding, it is not vulnerable.
  • Using hyper as a server or client. The body would be improperly truncated in either case.
  • Users send requests or responses with chunk sizes greater than 18 exabytes.

To determine if vulnerable to desync attacks, these things must be true:

  • Using an upstream proxy that allows chunks sizes larger than 64-bit. If the proxy rejects chunk sizes that are too large, that request won't be forwarded to hyper.

Patches

We have released the following patch versions:

  • v0.14.10 (to be released when this advisory is published)

Workarounds

Besides upgrading hyper, you can take the following options:

  • Reject requests manually that contain a Transfer-Encoding header.
  • Ensure any upstream proxy rejects Transfer-Encoding chunk sizes greater than what fits in 64-bit unsigned integers.

Credits

This issue was initially reported by Mattias Grenfeldt and Asta Olofsson.

References

@seanmonstar seanmonstar published to hyperium/hyper Jul 7, 2021
Reviewed Jul 7, 2021
Published by the National Vulnerability Database Jul 7, 2021
Published to the GitHub Advisory Database Jul 12, 2021
Last updated Feb 3, 2023

Severity

Moderate

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
High
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:H/PR:N/UI:N/S:U/C:N/I:N/A:H

EPSS score

0.115%
(46th percentile)

Weaknesses

CVE ID

CVE-2021-32714

GHSA ID

GHSA-5h46-h7hh-c6x9

Source code

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.