hyper is an HTTP library for rust. hyper's HTTP/1 server code had a flaw that incorrectly parses and accepts requests with a `Content-Length` header with a prefixed plus sign, when it should have been rejected as illegal. This combined with an upstream HTTP proxy that doesn't parse such `Content-Length` headers, but forwards them, can result in "request smuggling" or "desync attacks". The flaw exists in all prior versions of hyper prior to 0.14.10, if built with `rustc` v1.5.0 or newer. The vulnerability is patched in hyper version 0.14.10. Two workarounds exist: One may reject requests manually that contain a plus sign prefix in the `Content-Length` header or ensure any upstream proxy handles `Content-Length` headers with a plus sign prefix.
Affected: crates.io: hyper
### Summary
hyper's HTTP/1 server code had a flaw that incorrectly parses and accepts requests with a `Content-Length` header with a prefixed plus sign, when it should have been rejected as illegal. This combined with an upstream HTTP proxy that doesn't parse such `Content-Length` headers, but forwards them, can result in "request smuggling" or "desync attacks".
### Vulnerability
The flaw exists in all prior versions of hyper, if built with [`rustc` v1.5.0 or newer](https://github.com/rust-lang/rust/pull/28826/commits/123a83326fb95366e94a3be1a74775df4db97739).
Example:
``` GET / HTTP/1.1 Host: example.com Content-Length: +3
abc ```
This request gets accepted and hyper reads the body as abc. The request _should_ be rejected, according to RFC 7230, since the ABNF for `Content-Length` only allows for `DIGIT`s. This is due to using the `FromStr` implementation for `u64` in the standard library. By differing from the spec, it is possible to send requests like these to endpoints that have different HTTP implementations, with different interpretations of the payload semantics, and cause "desync attacks".
In this particular case, an upstream proxy would need to error when parsing the `Content-Length`, but _not_ reject the request (swallowing its own error), and forwarding the request as-is with the `Content-Length` still included. _Then_ the upstream proxy and hyper would disagree on the length of the request body. The combination of these factors would be extremely rare.
R…
afterburn-5.0.0-6.1 on GA media
Affected: crates.io: hyper
`hyper`'s HTTP header parser accepted, according to RFC 7230, illegal contents inside `Content-Length` headers. Due to this, upstream HTTP proxies that ignore the header may still forward them along if it chooses to ignore the error.
To be vulnerable, `hyper` must be used as an HTTP/1 server and using an HTTP proxy upstream that ignores the header's contents but still forwards it. Due to all the factors that must line up, an attack exploiting this vulnerability is unlikely.
Affected: Ubuntu:20.04:LTS: rust-hyper
hyper is an HTTP library for rust. hyper's HTTP/1 server code had a flaw that incorrectly parses and accepts requests with a `Content-Length` header with a prefixed plus sign, when it should have been rejected as illegal. This combined with an upstream HTTP proxy that doesn't parse such `Content-Length` headers, but forwards them, can result in "request smuggling" or "desync attacks". The flaw exists in all prior versions of hyper prior to 0.14.10, if built with `rustc` v1.5.0 or newer. The vulnerability is patched in hyper version 0.14.10. Two workarounds exist: One may reject requests manually that contain a plus sign prefix in the `Content-Length` header or ensure any upstream proxy handles `Content-Length` headers with a plus sign prefix.