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

Bugfix 🐛

• fixes a regression introduced in #153 wherein query and fragment were stripped (#161)

Bugfixes 🐛

• Fixes the handling of urls that start with multiple slashes, like http://example.com//double/slashes #153

Features ✨

• Adds support for protocol upgrades, unlocking experimental websockets support #159
• Adds support for client chunked encoding, allowing the streaming of bodies with indeterminate length #158

Internal 🏗️

• Rewrote test suite in preparation for above changes #157
• Chunked encoder is now shared between client and server #158
• Rewrote the client and server encoders for readability #158

🐛 Bugfix

• For each header from an incoming request, use append instead of insert

Fixes two bugs in async-h1:

• #139: we no longer send 100-continue until the body has been read
  from

• #143: allow chunked decoder to read poll after eof -- this resolves
  an issue with async_std::io::copy

This patch ensures we always populate the Request::version field when parsing requests.

Fixes

• Set request version #131

This patch fixes an issue in the client where we were incorrectly sending the URL fragment (#fragment) on requests.

Fixes

• Don't send URL fragment in client #128
• Update contributing link in README.md #129

Changes

• Update text on minimum supported Rust version #127

v2.1.0

Compare

Choose a tag to compare