I'm confused by the fact that there's no mention of interaction with the Hyper project's authors. I'm fairly certain that Sean & contributors will want to address the underlying issue, if they haven't already done so (clearly they were describing the potential for misusing the Hyper API very directly in the docs!), and pointing that out and clearly stating when and how that has been or will be addressed would shine a much more positive light on everyone, including the security researchers.<p>I see that there's an 1.0 RC release and the offending API seems to have changed and is probably not amenable to this type of misuse any more. The article authors could have easily added some info about that -- I certainly would have appreciated not having to go looking for that myself.
> single Bytes buffer, for example the following unsafe usage<p>Highlighting “unsafe” in red in an article about a Rust package when talking about something which is not Unsafe is so cursed.
Maybe there shouldn't be a<p><pre><code> to_bytes(body) -> Bytes
</code></pre>
function at all ?<p>Only a<p><pre><code> to_bytes(body: B, max_size: Option<usize>)
</code></pre>
This way if someone REALLY wants the behavior that potentially results in a crash, they still have access to it, but have to be really explicit about it.
Rouille, another Rust HTTP server, can also trivially be DOS'd by sending a Content-Length that doesn't match the actual content length.<p>But HTTP implementations like these are not really meant to directly face the internet. They usually sit behind reverse proxies/API gateways/CDNs.
Good to see public sharing not only of such a problem, but also how to fix it in your own code.<p>I am a bit disconcerted that something that apparently is warned against in the docs, is done across several "big" packages that use Hyper. Maybe with a more appropriate name exposed by the library, for example `to_bytes_unchecked`, such "bad" uses would be less wide-spread.
Seemingly related PR <a href="https://github.com/hyperium/hyper/pull/3046">https://github.com/hyperium/hyper/pull/3046</a>
I assume most production environments will run a reverse proxy like nginx which have sensible defaults. Good find nonetheless. Should be patched by Hyper.
Will falliable allocations help eliminate these kinds of DoS vulnerabilities?<p>AFAIK there's a proposal: <a href="https://rust-lang.github.io/rfcs/2116-alloc-me-maybe.html" rel="nofollow">https://rust-lang.github.io/rfcs/2116-alloc-me-maybe.html</a>
What's interesting to me is we've known about these class of API misdesign issues since gets(3)... sometimes convenient and ergonomic is really not the right way to do it.