-
Notifications
You must be signed in to change notification settings - Fork 17.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
x/net/http2/h2c: ineffective mitigation for unsafe io.ReadAll #56352
Comments
Change https://go.dev/cl/447396 mentions this issue: |
In the Go upstream http2 library, a DOS vector was introduced. The fix for the DOS introduces a request smuggling vulnerability. See golang/go#56352. All of these are related to h2c upgrades; we don't actually care about this - we only want HTTP/2 prior knowledge and HTTP/1.1. This PR introduces a wrapper around the h2c library denying h2c upgrades. It also enforces via linting that this is used.
In the Go upstream http2 library, a DOS vector was introduced. The fix for the DOS introduces a request smuggling vulnerability. See golang/go#56352. All of these are related to h2c upgrades; we don't actually care about this - we only want HTTP/2 prior knowledge and HTTP/1.1. This PR introduces a wrapper around the h2c library denying h2c upgrades. It also enforces via linting that this is used.
In the Go upstream http2 library, a DOS vector was introduced. The fix for the DOS introduces a request smuggling vulnerability. See golang/go#56352. All of these are related to h2c upgrades; we don't actually care about this - we only want HTTP/2 prior knowledge and HTTP/1.1. This PR introduces a wrapper around the h2c library denying h2c upgrades. It also enforces via linting that this is used.
@gopherbot please open backport issues, this is a potential request smuggling vector |
Backport issue(s) opened: #56675 (for 1.18), #56676 (for 1.19). Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases. |
In the Go upstream http2 library, a DOS vector was introduced. The fix for the DOS introduces a request smuggling vulnerability. See golang/go#56352. All of these are related to h2c upgrades; we don't actually care about this - we only want HTTP/2 prior knowledge and HTTP/1.1. This PR introduces a wrapper around the h2c library denying h2c upgrades. It also enforces via linting that this is used. Co-authored-by: John Howard <howardjohn@google.com>
When processing an HTTP/1 Upgrade: h2c request, detect errors reading the request body and fail the request rather than passing off the partially-read request to the HTTP/2 server. Correctly handles the case where a MaxBytesHandler has limited the size of the initial HTTP/1 request body. Fixes golang/go#56352 Change-Id: I08d60953cea26961cffbab3094cc1b44236f4e37 Reviewed-on: https://go-review.googlesource.com/c/net/+/447396 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: John Howard <howardjohn@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Damien Neil <dneil@google.com>
This is CVE-2022-41721. |
Is this public? As far as I can see it's still private -- is this intentional? https://cve.report/CVE-2022-41721 |
In the Go upstream http2 library, a DOS vector was introduced. The fix for the DOS introduces a request smuggling vulnerability. See golang/go#56352. All of these are related to h2c upgrades; we don't actually care about this - we only want HTTP/2 prior knowledge and HTTP/1.1. This PR introduces a wrapper around the h2c library denying h2c upgrades. It also enforces via linting that this is used. Co-authored-by: John Howard <howardjohn@google.com>
In the Go upstream http2 library, a DOS vector was introduced. The fix for the DOS introduces a request smuggling vulnerability. See golang/go#56352. All of these are related to h2c upgrades; we don't actually care about this - we only want HTTP/2 prior knowledge and HTTP/1.1. This PR introduces a wrapper around the h2c library denying h2c upgrades. It also enforces via linting that this is used. Co-authored-by: John Howard <howardjohn@google.com> Co-authored-by: Istio Automation <istio-testing-bot@google.com> Co-authored-by: John Howard <howardjohn@google.com>
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
What did you do?
In https://go.dev/cl/407454, an
io.ReadAll(r.Body)
call was added to the h2c handler. This is unsafe for untrusted inputs generally. The CL also adds a comment (https://go-review.googlesource.com/c/net/+/407454/4/http2/h2c/h2c.go) to useMaxBytesHandler
if this is an issue.There are two issues here:
Not much that can be done now, but this essentially introduced a DOS vector into the http2 library without any release notes. While the comment is helpful, most users probably don't read the full diff of changes in core libraries like this. It would be nice to have more visibility into unsafe changes, or to make them opt-in, in the future.
The mitigation provided isn't useable in many cases
Consider the following program:
I then run the following curls:
Up until the final call, memory usage is ~0. Its only the final call that is an issue.
However, if I add the
MaxBytesHandler
, all of them are broken.Its also not possible to just disable H2c upgrade and allow only prior knowledge or http/1.1.
One solution could be to try to make a
MaxBytesHandlerForH2CUpdate
, copying theisH2CUpgrade
and hoping the internal logic never changes. Something like:However, I would expect that it is possible to use h2c in a secure manner without resorting to workarounds like this.
The text was updated successfully, but these errors were encountered: