-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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: memory exhaustion in Request.ParseMultipartForm [CVE-2023-45290] #65383
Comments
@gopherbot please open backport issues for this security fix. |
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: |
…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 <[email protected]> Reviewed-by: Tatiana Bradley <[email protected]> Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/2174345 Reviewed-by: Carlos Amedee <[email protected]> Reviewed-on: https://go-review.googlesource.com/c/go/+/569237 Reviewed-by: Carlos Amedee <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Auto-Submit: Michael Knyszek <[email protected]>
…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 <[email protected]> Reviewed-by: Tatiana Bradley <[email protected]> Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/2173776 Reviewed-by: Carlos Amedee <[email protected]> Reviewed-on: https://go-review.googlesource.com/c/go/+/569240 Auto-Submit: Michael Knyszek <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Reviewed-by: Carlos Amedee <[email protected]>
…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 <[email protected]> Reviewed-by: Tatiana Bradley <[email protected]> Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/2174345 Reviewed-by: Carlos Amedee <[email protected]> Reviewed-on: https://go-review.googlesource.com/c/go/+/569237 Reviewed-by: Carlos Amedee <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Auto-Submit: Michael Knyszek <[email protected]>
Change https://go.dev/cl/569341 mentions this issue: |
…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 <[email protected]> Reviewed-by: Tatiana Bradley <[email protected]> Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/2174345 Reviewed-by: Carlos Amedee <[email protected]> Reviewed-on: https://go-review.googlesource.com/c/go/+/569237 Reviewed-by: Carlos Amedee <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Auto-Submit: Michael Knyszek <[email protected]>
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: