net/http, net/textproto: denial of service from excessive memory allocation (CVE-2023-24534) #58975
Assignees
Labels
FrozenDueToAge
NeedsFix
The path to resolution is known, but the work has not been done.
release-blocker
Security
Milestone
Comments
dmitshur
added
the
NeedsFix
|
@gopherbot please open backport issues |
|
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. |
|
Change https://go.dev/cl/481976 mentions this issue: |
|
Change https://go.dev/cl/481982 mentions this issue: |
|
Change https://go.dev/cl/481988 mentions this issue: |
|
Change https://go.dev/cl/481994 mentions this issue: |
gopherbot
pushed a commit
that referenced
this issue
Apr 4, 2023
…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 <[email protected]> Reviewed-by: Roland Shoemaker <[email protected]> Reviewed-by: Julie Qiu <[email protected]> (cherry picked from commit f739f080a72fd5b06d35c8e244165159645e2ed6) Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1802393 Reviewed-by: Damien Neil <[email protected]> Run-TryBot: Roland Shoemaker <[email protected]> Change-Id: I675451438d619a9130360c56daf529559004903f Reviewed-on: https://go-review.googlesource.com/c/go/+/481982 Run-TryBot: Michael Knyszek <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Matthew Dempsky <[email protected]> Auto-Submit: Michael Knyszek <[email protected]>
gopherbot
pushed a commit
that referenced
this issue
Apr 4, 2023
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 <[email protected]> Reviewed-by: Roland Shoemaker <[email protected]> Reviewed-by: Julie Qiu <[email protected]> Change-Id: Iacc1c2b5ea6509529845a972414199f988ede1e5 Reviewed-on: https://go-review.googlesource.com/c/go/+/481994 Reviewed-by: Matthew Dempsky <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Run-TryBot: Michael Knyszek <[email protected]> Auto-Submit: Michael Knyszek <[email protected]>
gopherbot
pushed a commit
that referenced
this issue
Apr 4, 2023
…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 <[email protected]> Reviewed-by: Roland Shoemaker <[email protected]> Reviewed-by: Julie Qiu <[email protected]> Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1802397 Run-TryBot: Roland Shoemaker <[email protected]> TryBot-Result: Security TryBots <[email protected]> Reviewed-on: https://go-review.googlesource.com/c/go/+/481988 Run-TryBot: Michael Knyszek <[email protected]> TryBot-Bypass: Michael Knyszek <[email protected]> Auto-Submit: Michael Knyszek <[email protected]> Reviewed-by: Matthew Dempsky <[email protected]>
mknyszek
changed the title
|
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. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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
The text was updated successfully, but these errors were encountered: