hyper known bugs

Affected versions of this crate called `mem::uninitialized()` in the HTTP1 parser to create values of type `httparse::Header` (from the `httparse` crate). This is unsound, since `Header` contains references and thus must be non-null. The flaw was corrected by avoiding the use of `mem::uninitialized()`, using `MaybeUninit` instead.

Affected versions of this crate called `mem::uninitialized()` in the HTTP1 parser to create values of type `httparse::Header` (from the `httparse` crate). This is unsound, since `Header` contains references and thus must be non-null. The flaw was corrected by avoiding the use of `mem::uninitialized()`, using `MaybeUninit` instead.

When decoding chunk sizes that are too large, `hyper`'s code would encounter an integer overflow. Depending on the situation, this could lead to data loss from an incorrect total size, or in rarer cases, a request smuggling attack. To be vulnerable, you must be using `hyper` for any HTTP/1 purpose, including as a client or server, and consumers must send requests or responses that specify a chunk size greater than 18 exabytes. For a possible request smuggling attack to be possible, any upstream proxies must accept a chunk size greater than 64 bits.

`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.

hyper's HTTP server code had a flaw that incorrectly understands some requests with multiple transfer-encoding headers to have a chunked payload, when it should have been rejected as illegal. This combined with an upstream HTTP proxy that understands the request payload boundary differently can result in "request smuggling" or "desync attacks".

Vulnerable versions of hyper allow GET requests to have bodies, even if there is no Transfer-Encoding or Content-Length header. As per the HTTP 1.1 specification, such requests do not have bodies, so the body will be interpreted as a separate HTTP request. This allows an attacker who can control the body and method of an HTTP request made by hyper to inject a request with headers that would not otherwise be allowed, as demonstrated by sending a malformed HTTP request from a Substrate runtime. This allows bypassing CORS restrictions. In combination with other vulnerabilities, such as an exploitable web server listening on loopback, it may allow remote code execution. The flaw was corrected in hyper version 0.12.34.

Serializing of headers to the socket did not filter the values for newline bytes (`\r` or `\n`), which allowed for header values to split a request or response. People would not likely include newlines in the headers in their own applications, so the way for most people to exploit this is if an application constructs headers based on unsanitized user input. This issue was fixed by replacing all newline characters with a space during serialization of a header value.

When used on Windows platforms, all versions of Hyper prior to 0.9.4 did not perform hostname verification when making HTTPS requests. This allows an attacker to perform MitM attacks by preventing any valid CA-issued certificate, even if there's a hostname mismatch. The problem was addressed by leveraging rust-openssl's built-in support for hostname verification.

Serializing of headers to the socket did not filter the values for newline bytes (\r or \n), which allowed for header values to split a request or response. People would not likely include newlines in the headers in their own applications, so the way for most people to exploit this is if an application constructs headers based on unsanitized user input. This issue was fixed by replacing all newline characters with a space during serialization of a header value.

When used on Windows platforms, all versions of Hyper prior to 0.9.4 did not perform hostname verification when making HTTPS requests. This allows an attacker to perform MitM attacks by preventing any valid CA-issued certificate, even if there's a hostname mismatch. The problem was addressed by leveraging rust-openssl's built-in support for hostname verification.

### Summary hyper's HTTP server code had a flaw that incorrectly understands some requests with multiple transfer-encoding headers to have a chunked payload, when it should have been rejected as illegal. This combined with an upstream HTTP proxy that understands the request payload boundary differently can result in "request smuggling" or "desync attacks". ### Vulnerability The flaw was introduced in https://github.com/hyperium/hyper/commit/26417fc24a7d05df538e0f39239b373c5c3d61f6, released in v0.12.0. Consider this example request: ``` POST /yolo HTTP/1.1 Transfer-Encoding: chunked Transfer-Encoding: cow ``` This request *should* be rejected, according to RFC 7230, since it has a `Transfer-Encoding` header, but after folding, it does not end in `chunked`. hyper would notice the `chunked` in the first line, and then check the second line, and thanks to a missing boolean assignment, *not* set the error condition. hyper would treat the payload as being `chunked`. 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". There are several parts of the spec that must also be checked, and hyper correctly handles all of those. Additionally, hyper's *client* does not allow sending requests with improper headers, so the misunderstanding cannot be propagated further. Read more about desync attacks: https://portswigger.net/research/http-desync-attacks-request-smuggling-reborn ### Impact To determine if vulnerable, all these things must be true: - **Using hyper as an HTTP *server*.** The client is not affected. - **Using HTTP/1.1.** HTTP/2 does not use `transfer-encoding`. - **Using a vulnerable HTTP proxy upstream to hyper.** If an upstream proxy correctly rejects the illegal transfer-encoding headers, the desync attack cannot succeed. If there is *no* proxy upstream of hyper, hyper cannot *start* the desync attack, as the client will repair the headers before forwarding. ### Patches We have released and backported the following patch versions: - v0.14.3 - v0.13.10 ### Workarounds Besides upgrading hyper, you can take the following options: - Reject requests that contain a `transfer-encoding` header. - Ensure any upstream proxy handles `transfer-encoding` correctly. ### Credits This issue was initially reported by ZeddYu Lu From Qi An Xin Technology Research Institute.

### 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](https://grenfeldt.dev/) and Asta Olofsson.

### 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. Read more about desync attacks: https://portswigger.net/research/http-desync-attacks-request-smuggling-reborn ### Impact To determine if vulnerable, all these things must be true: - **Using hyper as an HTTP server**. While the lenient decoder also exists in the client, a vulnerability does not exist around _responses_. - **Using HTTP/1**. The HTTP/2 code uses a stricter parser. - **Using a vulnerable HTTP proxy upstream to hyper**. If an upstream proxy correctly rejects the illegal `Content-Length` header, *OR* can parse the length with the plus sign, the desync attack cannot succeed. ### Patches We have released the following patch versions: - v0.14.10 (to be released when this advisor is published) ### Workarounds Besides upgrading hyper, you can take the following options: - Reject requests manually that contain a plus sign prefix in the `Content-Length` header. - Ensure any upstream proxy handles `Content-Length` headers with a plus sign prefix. ### Credits This issue was initially reported by [Mattias Grenfeldt](https://grenfeldt.dev/) and Asta Olofsson.

Vulnerable versions of hyper allow GET requests to have bodies, even if there is no Transfer-Encoding or Content-Length header. As per the HTTP 1.1 specification, such requests do not have bodies, so the body will be interpreted as a separate HTTP request. This allows an attacker who can control the body and method of an HTTP request made by hyper to inject a request with headers that would not otherwise be allowed, as demonstrated by sending a malformed HTTP request from a Substrate runtime. This allows bypassing CORS restrictions. In combination with other vulnerabilities, such as an exploitable web server listening on loopback, it may allow remote code execution. The flaw was corrected in hyper version 0.12.34.