Skip to content

net/http, net/textproto: denial of service from excessive memory allocation ​(CVE-2023-24534) #58975

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.

Sign up for GitHub

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

Jump to bottom
Closed
neild opened this issue Mar 10, 2023 · 7 comments
Closed

net/http, net/textproto: denial of service from excessive memory allocation ​(CVE-2023-24534) #58975

neild opened this issue Mar 10, 2023 · 7 comments
Assignees
@neild
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done. release-blocker Security
Milestone
Go1.21

Comments

@neild
Copy link
Contributor

neild commented Mar 10, 2023 •
edited by mknyszek
Loading

HTTP and MIME header parsing could allocate large amounts of memory, even when parsing small inputs.

Certain unusual patterns of input data could cause the common function used to parse HTTP and MIME headers to allocate substantially more memory than required to hold the parsed headers. An attacker can exploit this behavior to cause an HTTP server to allocate large amounts of memory from a small request, potentially leading to memory exhaustion and a denial of service.

Header parsing now correctly allocates only the memory required to hold parsed headers.

Thanks to Jakob Ackermann (@das7pad) for discovering this issue.

This is CVE-2023-24534 and Go issue https://go.dev/issue/58975.

/cc @golang/security and @golang/release
@neild neild added the Security label Mar 10, 2023
@neild neild self-assigned this Mar 10, 2023
@dmitshur dmitshur added this to the Go1.21 milestone Mar 17, 2023
@dmitshur dmitshur added the NeedsFix The path to resolution is known, but the work has not been done. label Mar 17, 2023
@julieqiu
Copy link
Member

@gopherbot please open backport issues

This was referenced Mar 27, 2023
Closed
Closed
@gopherbot
Copy link
Contributor

Backport issue(s) opened: #59267 (for 1.19), #59268 (for 1.20).

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

@gopherbot
Copy link
Contributor

Change https://go.dev/cl/481976 mentions this issue: [release-branch.go1.19] net/textproto: avoid overpredicting the number of MIME header keys

@gopherbot
Copy link
Contributor

Change https://go.dev/cl/481982 mentions this issue: [release-branch.go1.19] net/textproto: avoid overpredicting the number of MIME header keys

@gopherbot
Copy link
Contributor

Change https://go.dev/cl/481988 mentions this issue: [release-branch.go1.20] net/textproto: avoid overpredicting the number of MIME header keys

@gopherbot
Copy link
Contributor

Change https://go.dev/cl/481994 mentions this issue: net/textproto: avoid overpredicting the number of MIME header keys

gopherbot pushed a commit that referenced this issue Apr 4, 2023
@neild @gopherbot
[release-branch.go1.19] net/textproto: avoid overpredicting the numbe…
d6759e7 
…r of MIME header keys

A parsed MIME header is a map[string][]string. In the common case,
a header contains many one-element []string slices. To avoid
allocating a separate slice for each key, ReadMIMEHeader looks
ahead in the input to predict the number of keys that will be
parsed, and allocates a single []string of that length.
The individual slices are then allocated out of the larger one.

The prediction of the number of header keys was done by counting
newlines in the input buffer, which does not take into account
header continuation lines (where a header key/value spans multiple
lines) or the end of the header block and the start of the body.
This could lead to a substantial amount of overallocation, for
example when the body consists of nothing but a large block of
newlines.

Fix header key count prediction to take into account the end of
the headers (indicated by a blank line) and continuation lines
(starting with whitespace).

Thanks to Jakob Ackermann (@das7pad) for reporting this issue.

Fixes CVE-2023-24534
For #58975
Fixes #59267

Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1802452
Run-TryBot: Damien Neil <dneil@google.com>
Reviewed-by: Roland Shoemaker <bracewell@google.com>
Reviewed-by: Julie Qiu <julieqiu@google.com>
(cherry picked from commit f739f080a72fd5b06d35c8e244165159645e2ed6)
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1802393
Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Roland Shoemaker <bracewell@google.com>
Change-Id: I675451438d619a9130360c56daf529559004903f
Reviewed-on: https://go-review.googlesource.com/c/go/+/481982
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
gopherbot pushed a commit that referenced this issue Apr 4, 2023
@neild @gopherbot
net/textproto: avoid overpredicting the number of MIME header keys
66ae75f 
A parsed MIME header is a map[string][]string. In the common case,
a header contains many one-element []string slices. To avoid
allocating a separate slice for each key, ReadMIMEHeader looks
ahead in the input to predict the number of keys that will be
parsed, and allocates a single []string of that length.
The individual slices are then allocated out of the larger one.

The prediction of the number of header keys was done by counting
newlines in the input buffer, which does not take into account
header continuation lines (where a header key/value spans multiple
lines) or the end of the header block and the start of the body.
This could lead to a substantial amount of overallocation, for
example when the body consists of nothing but a large block of
newlines.

Fix header key count prediction to take into account the end of
the headers (indicated by a blank line) and continuation lines
(starting with whitespace).

Thanks to Jakob Ackermann (@das7pad) for reporting this issue.

For #58975
Fixes CVE-2023-24534

Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1802452
Run-TryBot: Damien Neil <dneil@google.com>
Reviewed-by: Roland Shoemaker <bracewell@google.com>
Reviewed-by: Julie Qiu <julieqiu@google.com>
Change-Id: Iacc1c2b5ea6509529845a972414199f988ede1e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/481994
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
gopherbot pushed a commit that referenced this issue Apr 4, 2023
@neild @gopherbot
[release-branch.go1.20] net/textproto: avoid overpredicting the numbe…
3991f6c 
…r of MIME header keys

A parsed MIME header is a map[string][]string. In the common case,
a header contains many one-element []string slices. To avoid
allocating a separate slice for each key, ReadMIMEHeader looks
ahead in the input to predict the number of keys that will be
parsed, and allocates a single []string of that length.
The individual slices are then allocated out of the larger one.

The prediction of the number of header keys was done by counting
newlines in the input buffer, which does not take into account
header continuation lines (where a header key/value spans multiple
lines) or the end of the header block and the start of the body.
This could lead to a substantial amount of overallocation, for
example when the body consists of nothing but a large block of
newlines.

Fix header key count prediction to take into account the end of
the headers (indicated by a blank line) and continuation lines
(starting with whitespace).

Thanks to Jakob Ackermann (@das7pad) for reporting this issue.

Fixes CVE-2023-24534
For #58975
Fixes #59268

Change-Id: I0591593e67b6fdba22a32dcc3334fad797727f5c
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1802452
Run-TryBot: Damien Neil <dneil@google.com>
Reviewed-by: Roland Shoemaker <bracewell@google.com>
Reviewed-by: Julie Qiu <julieqiu@google.com>
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1802397
Run-TryBot: Roland Shoemaker <bracewell@google.com>
TryBot-Result: Security TryBots <security-trybots@go-security-trybots.iam.gserviceaccount.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/481988
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Bypass: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
@mknyszek mknyszek changed the title security: fix ​CVE-2023-24534 net/http, net/textproto: denial of service from excessive memory allocation ​(CVE-2023-24534) Apr 4, 2023
@mknyszek
Copy link
Contributor

mknyszek commented Apr 5, 2023

I believe this has been resolved. The CL landed but just didn't have "Fixes" in the commit message.

@neild if that's not true please feel free to reopen.

@mknyszek mknyszek closed this as completed Apr 5, 2023
@KevinSolmssen KevinSolmssen mentioned this issue May 15, 2023
Closed
@golang golang locked and limited conversation to collaborators Apr 4, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@neild neild

Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done. release-blocker Security
Projects
None yet
Milestone
Go1.21
Development

No branches or pull requests
5 participants
@neild @mknyszek @dmitshur @julieqiu @gopherbot