Go 1.20.1 のリリース【セキュリティ・アップデート】

On Windows, the filepath.Clean function could transform an invalid path such as a/../c:/b into the valid path c:\b. This transformation of a relative (if invalid) path into an absolute path could enable a directory traversal attack. The filepath.Clean function will now transform this path into the relative (but still invalid) path .\c:\b.

Multipart form parsing with mime/multipart.Reader.ReadForm can consume largely unlimited amounts of memory and disk files. This also affects form parsing in the net/http package with the Request methods FormFile, FormValue, ParseMultipartForm, and PostFormValue.

[…]

ReadForm now properly accounts for various forms of memory overhead, and should now stay within its documented limit of 10MB + maxMemory bytes of memory consumption. Users should still be aware that this limit is high and may still be hazardous.

ReadForm now creates at most one on-disk temporary file, combining multiple form parts into a single temporary file. The mime/multipart.File interface type’s documentation states, “If stored on disk, the File’s underlying concrete type will be an *os.File.”. This is no longer the case when a form contains more than one file part, due to this coalescing of parts into a single file. The previous behavior of using distinct files for each form part may be reenabled with the environment variable GODEBUG=multipartfiles=distinct.

Users should be aware that multipart.ReadForm and the http.Request methods that call it do not limit the amount of disk consumed by temporary files. Callers can limit the size of form data with http.MaxBytesReader.

Both clients and servers may send large TLS handshake records which cause servers and clients, respectively, to panic when attempting to construct responses.

This affects all TLS 1.3 clients, TLS 1.2 clients which explicitly enable session resumption (by setting Config.ClientSessionCache to a non-nil value), and TLS 1.3 servers which request client certificates (by setting Config.ClientAuth >= RequestClientCert).

A maliciously crafted HTTP/2 stream could cause excessive CPU consumption in the HPACK decoder, sufficient to cause a denial of service from a small number of small requests.

This issue is also fixed in golang.org/x/net/http2 v0.7.0, for users manually configuring HTTP/2.

Version v0.5.0 of golang.org/x/image fixes a vulnerability in the golang.org/x/image/tiff package which could cause a denial of service.

An attacker can craft a malformed TIFF image which will consume a significant amount of memory when passed to DecodeConfig.