Skip to content

v2.3.0

Compare
Choose a tag to compare
@jbr jbr released this 18 Dec 00:59
· 25 commits to main since this release
b1651f3

Fix for smuggling vulnerability in async-h1

This release represents a fix for a flaw believed to have been present in all previous versions of async-h1, which have been yanked. This vulnerability affects any web server that uses async-h1 behind a reverse proxy, including all such Tide applications.

The flaw was as follows:

If the server endpoint does not attempt to read the body of a request which is longer than some specific and predictable buffer length, async-h1 will attempt to read a subsequent request from within the body content starting at that offset into the body.

One way to exploit this vulnerability would be for an adversary to craft a request such that the body contains a second request that would not be noticed by a reverse proxy, allowing the http client to forge forwarded/x-forwarded headers on the smuggled request. If an application trusted the authenticity of these headers, it could be misled by the smuggled request.

Another potential concern with this vulnerability is that if a reverse proxy is sending multiple http clients' requests along the same keep-alive connection, it would be possible for the smuggled request to specify a long content-length header and capture another user's request in its body. This content could be captured in a POST request to an endpoint that allows the content to be subsequently retrieved by the adversary.

Semver

We are releasing this as semver-minor in order to make upgrades easier. A survey of reverse dependencies indicated that nearly all users of async-h1 are using async_h1::server::accept, which is the primary server api of this crate, and which is unchanged by this fix. However, this release does represent a breaking change to the signature of decode, which while not the standard entrypoint to async-h1, is still part of our public API. We have made this tradeoff to prioritize the upgrade path for the overwhelming majority of users who only transitively depend on async-h1.

Yanking

We have yanked all previous versions of async-h1 from crates.io, as we believe that this vulnerability merits that action. Please contact us with any concerns about this choice.

Additional code in this release

This release also improves async-h1's keepalive handling, in that it now respects connection: close headers. It also includes improvements to the crate's testing tooling in order to reproduce the above bug in our tests.

Thanks

We would like to extend our appreciation to @Dirbaio, who identified this issue, patiently walked us through it, and helped explore potential solutions