Skip to content
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

net/http, x/net/http2: close connections when receiving too many headers (CVE-2023-45288) #65051

Closed
neild opened this issue Jan 10, 2024 · 21 comments · May be fixed by go-httprequest/httprequest#16
Assignees
Labels
NeedsFix The path to resolution is known, but the work has not been done. release-blocker Security
Milestone

Comments

@neild
Copy link
Contributor

neild commented Jan 10, 2024

Maintaining HPACK state requires that we parse and process all HEADERS and CONTINUATION frames on a connection. When a request's headers exceed MaxHeaderBytes, we don't allocate memory to store the excess headers but we do parse them. This permits an attacker to cause an HTTP/2 endpoint to read arbitrary amounts of header data, all associated with a request which is going to be rejected. These headers can include Huffman-encoded data which is significantly more expensive for the receiver to decode than for an attacker to send.

Set a limit on the amount of excess header frames we will process before closing a connection.

Thanks to Bartek Nowotarski (https://nowotarski.info/) for reporting this issue.

This is CVE-2023-45288 and Go issue https://go.dev/issue/65051 (this issue).


This is a PRIVATE issue for CVE-2023-45288, tracked in http://b/319262343 and fixed by http://tg/2130527.

/cc @golang/security and @golang/release

@neild neild self-assigned this Jan 10, 2024
@neild neild added this to the Go1.22 milestone Jan 11, 2024
@neild
Copy link
Contributor Author

neild commented Jan 30, 2024

@gopherbot please open backport issues for this security fix.

@gopherbot
Copy link

gopherbot commented Jan 30, 2024

Backport issue(s) opened: #65386 (for 1.20), #65387 (for 1.21), #66298 (for 1.22).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases.

@neild

This comment was marked as outdated.

@neild
Copy link
Contributor Author

neild commented Mar 27, 2024

We accidentally opened a duplicate issue for this: #66297. Closed that one in favor of keeping the original issue.

Current status: This is the main issue for CVE-2023-45288.
#65387 is the 1.21 backport
#66298 is the 1.22 backport

#65386 was the 1.20 backport, obsolete because we missed the 1.20 window.

@neild neild reopened this Mar 27, 2024
@dmitshur dmitshur added the NeedsFix The path to resolution is known, but the work has not been done. label Mar 27, 2024
@gopherbot
Copy link

Change https://go.dev/cl/576076 mentions this issue: [release-branch.go1.22] net/http: update bundled golang.org/x/net/http2

@gopherbot
Copy link

Change https://go.dev/cl/576075 mentions this issue: [release-branch.go1.21] net/http: update bundled golang.org/x/net/http2

gopherbot pushed a commit that referenced this issue Apr 3, 2024
Disable cmd/internal/moddeps test, since this update includes PRIVATE
track fixes.

Fixes CVE-2023-45288
For #65051
Fixes #66298

Change-Id: I5bbf774ebe7651e4bb7e55139d3794bd2b8e8fa8
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/2197227
Reviewed-by: Tatiana Bradley <tatianabradley@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/576076
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Bypass: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
gopherbot pushed a commit that referenced this issue Apr 3, 2024
Disable cmd/internal/moddeps test, since this update includes PRIVATE
track fixes.

Fixes CVE-2023-45288
For #65051
Fixes #65387

Change-Id: I17da6da2fe0dd70062b49f94377875acb34829a1
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/2197267
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
Reviewed-by: Tatiana Bradley <tatianabradley@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/576075
TryBot-Bypass: Dmitri Shuralyov <dmitshur@google.com>
Commit-Queue: Dmitri Shuralyov <dmitshur@golang.org>
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
@dmitshur dmitshur changed the title security: fix CVE-2023-45288 net/http, x/net/http2: close connections when receiving too many headers (CVE-2023-45288) Apr 3, 2024
@gopherbot
Copy link

Change https://go.dev/cl/576155 mentions this issue: http2: close connections when receiving too many headers

@gopherbot
Copy link

Change https://go.dev/cl/576215 mentions this issue: [internal-branch.go1.22-vendor] http2: close connections when receiving too many headers

@gopherbot
Copy link

Change https://go.dev/cl/576057 mentions this issue: [internal-branch.go1.21-vendor] http2: close connections when receiving too many headers

@geofffranks
Copy link

@neild @dmitshur Will there be an updated tag released for golang.org/x/net as well?

gopherbot pushed a commit to golang/net that referenced this issue Apr 3, 2024
…ng too many headers

Maintaining HPACK state requires that we parse and process
all HEADERS and CONTINUATION frames on a connection.
When a request's headers exceed MaxHeaderBytes, we don't
allocate memory to store the excess headers but we do
parse them. This permits an attacker to cause an HTTP/2
endpoint to read arbitrary amounts of data, all associated
with a request which is going to be rejected.

Set a limit on the amount of excess header frames we
will process before closing a connection.

Thanks to Bartek Nowotarski for reporting this issue.

Fixes CVE-2023-45288
For golang/go#65051

Change-Id: I15df097268df13bb5a9e9d3a5c04a8a141d850f6
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/2130527
Reviewed-by: Roland Shoemaker <bracewell@google.com>
Reviewed-by: Tatiana Bradley <tatianabradley@google.com>
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/2197243
Run-TryBot: Damien Neil <dneil@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-on: https://go-review.googlesource.com/c/net/+/576057
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
@TomSweeneyRedHat
Copy link

@neild Thanks for the confirmation!

pandrey2003 added a commit to pandrey2003/httprequest that referenced this issue Apr 10, 2024
pandrey2003 added a commit to pandrey2003/httprequest that referenced this issue Apr 10, 2024
pandrey2003 added a commit to pandrey2003/httprequest that referenced this issue Apr 10, 2024
Also fix golang/go#65051
and resolve obvious linting problems.
pandrey2003 added a commit to pandrey2003/httprequest that referenced this issue Apr 10, 2024
Also fix golang/go#65051
and resolve obvious linting problems.
@benjsmi
Copy link

benjsmi commented Apr 10, 2024

Can someone please clarify something for me? I have a Golang project that relies on net/http and has golang.org/x/net in its go.mod file.

Is it the case that moving my project to Go v1.21.9 is sufficient to address this issue? Or do I ALSO need to run go get -u golang.org/x/net@v0.23.0?

@rolandshoemaker
Copy link
Member

It is sufficient, unless you are directly importing the x/net/http2 package and using it to initialize HTTP2 servers.

ffromani added a commit to openshift-kni/numaresources-operator that referenced this issue Apr 16, 2024
Update x/net to pick up golang/net@ba87210
To fully fix we need to build with go >= 1.22.2.

xref: golang/go#65051

Signed-off-by: Francesco Romani <fromani@redhat.com>
ffromani added a commit to openshift-kni/scheduler-plugins that referenced this issue Apr 16, 2024
Update x/net to pick up golang/net@ba87210
To fully fix we need to build with go >= 1.22.2/1.21.9.

xref: golang/go#65051

Signed-off-by: Francesco Romani <fromani@redhat.com>
ffromani added a commit to openshift-kni/scheduler-plugins that referenced this issue Apr 16, 2024
Update x/net to pick up golang/net@ba87210
To fully fix we need to build with go >= 1.22.2/1.21.9.

xref: golang/go#65051

Signed-off-by: Francesco Romani <fromani@redhat.com>
ffromani added a commit to openshift-kni/scheduler-plugins that referenced this issue Apr 16, 2024
Update x/net to pick up golang/net@ba87210
To fully fix we need to build with go >= 1.22.2/1.21.9.

xref: golang/go#65051

Signed-off-by: Francesco Romani <fromani@redhat.com>
ffromani added a commit to openshift-kni/scheduler-plugins that referenced this issue Apr 16, 2024
Update x/net to pick up golang/net@ba87210
To fully fix we need to build with go >= 1.22.2/1.21.9.

xref: golang/go#65051

Signed-off-by: Francesco Romani <fromani@redhat.com>
ffromani added a commit to openshift-kni/scheduler-plugins that referenced this issue Apr 16, 2024
Update x/net to pick up golang/net@ba87210
To fully fix we need to build with go >= 1.22.2/1.21.9.

xref: golang/go#65051

Signed-off-by: Francesco Romani <fromani@redhat.com>
ffromani added a commit to openshift-kni/scheduler-plugins that referenced this issue Apr 16, 2024
Update x/net to pick up golang/net@ba87210
To fully fix we need to build with go >= 1.22.2/1.21.9.

xref: golang/go#65051

Signed-off-by: Francesco Romani <fromani@redhat.com>
ffromani added a commit to openshift-kni/numaresources-operator that referenced this issue Apr 17, 2024
Update x/net to pick up golang/net@ba87210
To fully fix we need to build with go >= 1.22.2.

xref: golang/go#65051

Signed-off-by: Francesco Romani <fromani@redhat.com>
ffromani added a commit to openshift-kni/numaresources-operator that referenced this issue Apr 17, 2024
Update x/net to pick up golang/net@ba87210
To fully fix we need to build with go >= 1.22.2.

xref: golang/go#65051

Signed-off-by: Francesco Romani <fromani@redhat.com>
ffromani added a commit to openshift-kni/numaresources-operator that referenced this issue Apr 17, 2024
Update x/net to pick up golang/net@ba87210
To fully fix we need to build with go >= 1.22.2.

xref: golang/go#65051

Signed-off-by: Francesco Romani <fromani@redhat.com>
ffromani added a commit to openshift-kni/scheduler-plugins that referenced this issue Apr 17, 2024
Update x/net to pick up golang/net@ba87210
To fully fix we need to build with go >= 1.22.2/1.21.9.

xref: golang/go#65051

Signed-off-by: Francesco Romani <fromani@redhat.com>
ffromani added a commit to openshift-kni/scheduler-plugins that referenced this issue Apr 17, 2024
Update x/net to pick up golang/net@ba87210
To fully fix we need to build with go >= 1.22.2/1.21.9.

xref: golang/go#65051

Signed-off-by: Francesco Romani <fromani@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsFix The path to resolution is known, but the work has not been done. release-blocker Security
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants