net/http: memory exhaustion in Request.ParseMultipartForm [CVE-2023-45290] #65383
Comments
|
@gopherbot please open backport issues for this security fix. |
This was referenced Jan 30, 2024
|
Backport issue(s) opened: #65388 (for 1.20), #65389 (for 1.21). 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 Please open a backport issue for Go 1.22 as well. |
|
I'll leave a note for the next release rotation person to do this after the release goes out, so it doesn't get lost. |
|
Change https://go.dev/cl/569237 mentions this issue: |
|
Change https://go.dev/cl/569240 mentions this issue: |
gopherbot
pushed a commit
that referenced
this issue
Mar 5, 2024
…d read in MIME header mime/multipart.Reader.ReadForm allows specifying the maximum amount of memory that will be consumed by the form. While this limit is correctly applied to the parsed form data structure, it was not being applied to individual header lines in a form. For example, when presented with a form containing a header line that never ends, ReadForm will continue to read the line until it runs out of memory. Limit the amount of data consumed when reading a header. Fixes CVE-2023-45290 Fixes #65850 For #65383 Change-Id: I7f9264d25752009e95f6b2c80e3d76aaf321d658 Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/2134435 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/+/2174345 Reviewed-by: Carlos Amedee <amedee@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/569237 Reviewed-by: Carlos Amedee <carlos@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Michael Knyszek <mknyszek@google.com>
gopherbot
pushed a commit
that referenced
this issue
Mar 5, 2024
…d read in MIME header mime/multipart.Reader.ReadForm allows specifying the maximum amount of memory that will be consumed by the form. While this limit is correctly applied to the parsed form data structure, it was not being applied to individual header lines in a form. For example, when presented with a form containing a header line that never ends, ReadForm will continue to read the line until it runs out of memory. Limit the amount of data consumed when reading a header. Fixes CVE-2023-45290 Fixes #65389 For #65383 Change-Id: I7f9264d25752009e95f6b2c80e3d76aaf321d658 Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/2134435 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/+/2173776 Reviewed-by: Carlos Amedee <amedee@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/569240 Auto-Submit: Michael Knyszek <mknyszek@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Carlos Amedee <carlos@golang.org>
mknyszek
changed the title
bradfitz
pushed a commit
to tailscale/go
that referenced
this issue
Mar 5, 2024
…d read in MIME header mime/multipart.Reader.ReadForm allows specifying the maximum amount of memory that will be consumed by the form. While this limit is correctly applied to the parsed form data structure, it was not being applied to individual header lines in a form. For example, when presented with a form containing a header line that never ends, ReadForm will continue to read the line until it runs out of memory. Limit the amount of data consumed when reading a header. Fixes CVE-2023-45290 Fixes golang#65850 For golang#65383 Change-Id: I7f9264d25752009e95f6b2c80e3d76aaf321d658 Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/2134435 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/+/2174345 Reviewed-by: Carlos Amedee <amedee@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/569237 Reviewed-by: Carlos Amedee <carlos@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Michael Knyszek <mknyszek@google.com>
|
Change https://go.dev/cl/569341 mentions this issue: |
romaindoumenc
pushed a commit
to TroutSoftware/go
that referenced
this issue
Mar 6, 2024
…d read in MIME header mime/multipart.Reader.ReadForm allows specifying the maximum amount of memory that will be consumed by the form. While this limit is correctly applied to the parsed form data structure, it was not being applied to individual header lines in a form. For example, when presented with a form containing a header line that never ends, ReadForm will continue to read the line until it runs out of memory. Limit the amount of data consumed when reading a header. Fixes CVE-2023-45290 Fixes golang#65850 For golang#65383 Change-Id: I7f9264d25752009e95f6b2c80e3d76aaf321d658 Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/2134435 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/+/2174345 Reviewed-by: Carlos Amedee <amedee@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/569237 Reviewed-by: Carlos Amedee <carlos@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Michael Knyszek <mknyszek@google.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When parsing a multipart form (either explicitly with Request.ParseMultipartForm or implicitly with Request.FormValue, Request.PostFormValue, or Request.FormFile), limits on the total size of the parsed form were not applied to the memory consumed while reading a single form line. This permitted a maliciously crafted input containing very long lines to cause allocation of arbitrarily large amounts of memory, potentially leading to memory exhaustion.
ParseMultipartForm now correctly limits the maximum size of form lines.
Thanks to Bartek Nowotarski for reporting this issue. This is CVE-2023-45290.
The text was updated successfully, but these errors were encountered: