ghsa-5h46-h7hh-c6x9
Vulnerability from github
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-Encodingheader. - Ensure any upstream proxy rejects
Transfer-Encodingchunk sizes greater than what fits in 64-bit unsigned integers.
Credits
This issue was initially reported by Mattias Grenfeldt and Asta Olofsson.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "hyper"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.14.10"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-32714"
],
"database_specific": {
"cwe_ids": [
"CWE-190"
],
"github_reviewed": true,
"github_reviewed_at": "2021-07-07T20:05:15Z",
"nvd_published_at": "2021-07-07T20:15:00Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nhyper\u0027s 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\".\n\n### Vulnerability\n\nExample:\n\n```\nGET / HTTP/1.1\nHost: example.com\nTransfer-Encoding: chunked\n\nf0000000000000003\nabc\n0\n\n```\n\nhyper 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.\n\nRead more about desync attacks: https://portswigger.net/research/http-desync-attacks-request-smuggling-reborn\n\n### Impact\n\nTo determine if vulnerable to _data loss_, these things must be true:\n\n- **Using HTTP/1.1.** Since HTTP/2 does not use chunked encoding, it is not vulnerable.\n- **Using hyper as a server or client.** The body would be improperly truncated in either case.\n- **Users send requests or responses with chunk sizes greater than 18 exabytes**.\n\nTo determine if vulnerable to _desync attacks_, these things must be true:\n\n- **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\u0027t be forwarded to hyper.\n\n### Patches\n\nWe have released the following patch versions:\n\n - v0.14.10 (to be released when this advisory is published)\n\n### Workarounds\n\nBesides upgrading hyper, you can take the following options:\n\n- Reject requests manually that contain a `Transfer-Encoding` header.\n- Ensure any upstream proxy rejects `Transfer-Encoding` chunk sizes greater than what fits in 64-bit unsigned integers.\n\n\n### Credits\nThis issue was initially reported by [Mattias Grenfeldt](https://grenfeldt.dev/) and Asta Olofsson.",
"id": "GHSA-5h46-h7hh-c6x9",
"modified": "2021-09-07T21:47:36Z",
"published": "2021-07-12T16:55:37Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/hyperium/hyper/security/advisories/GHSA-5h46-h7hh-c6x9"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-32714"
},
{
"type": "PACKAGE",
"url": "https://github.com/hyperium/hyper"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2021-0079.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Integer Overflow in Chunked Transfer-Encoding"
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.