Rust projects open to denial of service thanks to Hyper mistakes

If only there were some way to avoid...oh, there is? RTFM

Security researchers at have identified multiple vulnerabilities arising from careless use of the Rust Hyper package, a very popular library for handling HTTP requests.

Security firm JFrog found that an undisclosed number of projects incorporating Hyper, like Axum, Salvo and conduit-hyper, were susceptible to denial of service (DoS) attacks arising from HTTP requests crafted to take advantage of the vulnerabilities.

Those three have fixed their code, but an undisclosed number of other vulnerable projects have not yet responded, according to JFrog. Currently, 2,579 projects listed in Rust's package repository crates.io depend on Hyper, which has been downloaded more than 67 million times.

"These multiple vulnerabilities in various Rust packages stem from the same root cause – forgetting to set proper limits on HTTP requests when using the Hyper library," said Shachar Menashe, senior director of JFrog Security Research, in a blog post. "The lack of size limitations while using Hyper is a very serious issue that can be easily exploited by attackers to crash both HTTP clients and servers."

RTFM

The problem identified by the JFrog researchers resides in to_bytes, a function for copying a request or response body to a single Bytes buffer. It can be invoked in an inadvisable manner (for both unsafe and safe Rust) by failing to set header size limits – something explicitly warned against in the function's documentation.

The function reads chunks of data and can create a Vector with enough space for the expected length of the request body. But the size of the Vector comes from the "Content-Length" header which gets passed directly to the Rust memory allocator, explain Menashe and JFrog researcher Ori Hollander. So if that's too large, the allocator will panic and crash the process.

Ensuring that the "Content-Length" header value is suitably sized has been left to developers. RFC 7230 for HTTP/1.1 Message Syntax and Routing (June 2014) notes, "HTTP does not place a predefined limit on the length of each header field or on the length of the header section as a whole" and advises developers that servers receiving a larger-than-anticipated request header field or set of fields should respond with a 4xx client error status code.

This issue has come up before. In 2014 and in 2015, Hyper's developers fixed DoS vulnerabilities arising from receipt of excessively large request headers. Last year, in a related issues post, Rust developer Michal Varner suggested the incorporation of a warning mechanism.

He wrote, "[I]f the client is sending with chunked encoding, the header is optional. That makes the function [aggregate] (and its sibling to_bytes) potential DoS hazard."

We know how to write secure code. We're just not very good at doing so. ®