rustsec-2020-0093
Vulnerability from osv_rustsec
This vulnerability affects any webserver that uses async-h1 behind a reverse proxy, including all such Tide applications.
If the server does not read the body of a request which is longer than some buffer length, async-h1 will attempt to read a subsequent request from 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 request that would not be noticed by a reverse proxy, allowing it to forge forwarded/x-forwarded headers. 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 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.
The flaw was corrected in commit 7df79f by ensuring that the request body is always consumed from the tcp stream before attempting to read subsequent keep-alive request headers from it.
{
"affected": [
{
"database_specific": {
"categories": [],
"cvss": null,
"informational": null
},
"ecosystem_specific": {
"affected_functions": null,
"affects": {
"arch": [],
"functions": [
"async_h1::server::accept",
"async_h1::server::decode"
],
"os": []
}
},
"package": {
"ecosystem": "crates.io",
"name": "async-h1",
"purl": "pkg:cargo/async-h1"
},
"ranges": [
{
"events": [
{
"introduced": "0.0.0-0"
},
{
"fixed": "2.3.0"
}
],
"type": "SEMVER"
}
],
"versions": []
}
],
"aliases": [
"CVE-2020-26281",
"CVE-2020-36202",
"GHSA-4vr9-8cjf-vf9c",
"GHSA-c8rq-crxj-mj9m"
],
"database_specific": {
"license": "CC0-1.0"
},
"details": "This vulnerability affects any webserver that uses async-h1 behind a reverse proxy, including all such Tide applications.\n\nIf the server does not read the body of a request which is longer than some buffer length, async-h1 will attempt to read a subsequent request from the body content starting at that offset into the body.\n\nOne way to exploit this vulnerability would be for an adversary to craft a request such that the body contains a request that would not be noticed by a reverse proxy, allowing it to forge forwarded/x-forwarded headers. If an application trusted the authenticity of these headers, it could be misled by the smuggled request.\n\nAnother potential concern with this vulnerability is that if a reverse proxy is sending multiple http clients\u0027 requests along the same keep-alive connection, it would be possible for the smuggled request to specify a long content and capture another user\u0027s 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.\n\nThe flaw was corrected in commit [7df79f](https://github.com/http-rs/async-h1/commit/7df79f1d5d99fc0f492b315eebc7f0d301a85212) by ensuring that the request body is always consumed from the tcp stream before attempting to read subsequent keep-alive request headers from it.",
"id": "RUSTSEC-2020-0093",
"modified": "2023-06-13T13:10:24Z",
"published": "2020-12-17T12:00:00Z",
"references": [
{
"type": "PACKAGE",
"url": "https://crates.io/crates/async-h1"
},
{
"type": "ADVISORY",
"url": "https://rustsec.org/advisories/RUSTSEC-2020-0093.html"
},
{
"type": "WEB",
"url": "https://github.com/http-rs/async-h1/releases/tag/v2.3.0"
}
],
"related": [],
"severity": [],
"summary": "Async-h1 request smuggling possible with long unread bodies"
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.