This isn't full multi support like other languages yet, but for now simply a
way for a package to indicate that it requires a specific version of go.
Useful for things like wireguard-go which currently do not build with 1.21.
These minor releases include 2 security fixes following the security policy:
- path/filepath: recognize \??\ as a Root Local Device path prefix.
On Windows, a path beginning with \??\ is a Root Local Device path equivalent
to a path beginning with \\?\. Paths with a \??\ prefix may be used to access
arbitrary locations on the system. For example, the path \??\c:\x is
equivalent to the more common path c:\x.
The filepath package did not recognize paths with a \??\ prefix as special.
Clean could convert a rooted path such as \a\..\??\b into
the root local device path \??\b. It will now convert this
path into .\??\b.
IsAbs did not report paths beginning with \??\ as absolute.
It now does so.
VolumeName now reports the \??\ prefix as a volume name.
Join(`\`, `??`, `b`) could convert a seemingly innocent
sequence of path elements into the root local device path
\??\b. It will now convert this to \.\??\b.
This is CVE-2023-45283 and https://go.dev/issue/63713.
- path/filepath: recognize device names with trailing spaces and superscripts
The IsLocal function did not correctly detect reserved names in some cases:
reserved names followed by spaces, such as "COM1 ".
"COM" or "LPT" followed by a superscript 1, 2, or 3.
IsLocal now correctly reports these names as non-local.
This is CVE-2023-45284 and https://go.dev/issue/63713.
I did a verification bulk build with this change and updated all the
packages that were broken by this (kubo, ipget, caddy, etc.), so I hope
that this does not introduce any breakage.
net/http: rapid stream resets can cause excessive work
A malicious HTTP/2 client which rapidly creates requests and
immediately resets them can cause excessive server resource consumption.
While the total number of requests is bounded to the
http2.Server.MaxConcurrentStreams setting, resetting an in-progress
request allows the attacker to create a new request while the existing
one is still executing.
HTTP/2 servers now bound the number of simultaneously executing
handler goroutines to the stream concurrency limit. New requests
arriving when at the limit (which can only happen after the client
has reset an existing, in-flight request) will be queued until a
handler exits. If the request queue grows too large, the server
will terminate the connection.
This issue is also fixed in golang.org/x/net/http2 v0.17.0,
for users manually configuring HTTP/2.
The default stream concurrency limit is 250 streams (requests)
per HTTP/2 connection. This value may be adjusted using the
golang.org/x/net/http2 package; see the Server.MaxConcurrentStreams
setting and the ConfigureServer function.
This is CVE-2023-39325 and Go issue https://go.dev/issue/63417.
This is also tracked by CVE-2023-44487.
1.21.3
net/http: rapid stream resets can cause excessive work
A malicious HTTP/2 client which rapidly creates requests and
immediately resets them can cause excessive server resource consumption.
While the total number of requests is bounded to the
http2.Server.MaxConcurrentStreams setting, resetting an in-progress
request allows the attacker to create a new request while the existing
one is still executing.
HTTP/2 servers now bound the number of simultaneously executing
handler goroutines to the stream concurrency limit. New requests
arriving when at the limit (which can only happen after the client
has reset an existing, in-flight request) will be queued until a
handler exits. If the request queue grows too large, the server
will terminate the connection.
This issue is also fixed in golang.org/x/net/http2 v0.17.0,
for users manually configuring HTTP/2.
The default stream concurrency limit is 250 streams (requests)
per HTTP/2 connection. This value may be adjusted using the
golang.org/x/net/http2 package; see the Server.MaxConcurrentStreams
setting and the ConfigureServer function.
This is CVE-2023-39325 and Go issue https://go.dev/issue/63417.
This is also tracked by CVE-2023-44487.
1.21.2
cmd/go: line directives allows arbitrary execution during build
"//line" directives can be used to bypass the restrictions on "//go:cgo_"
directives, allowing blocked linker and compiler flags to be passed during
compliation. This can result in unexpected execution of arbitrary code when
running "go build". The line directive requires the absolute path of the file in
which the directive lives, which makes exploting this issue significantly more
complex.
This is CVE-2023-39323 and Go issue https://go.dev/issue/63211.
cmd/go: line directives allows arbitrary execution during build
"//line" directives can be used to bypass the restrictions on "//go:cgo_"
directives, allowing blocked linker and compiler flags to be passed during
compliation. This can result in unexpected execution of arbitrary code when
running "go build". The line directive requires the absolute path of the file in
which the directive lives, which makes exploting this issue significantly more
complex.
This is CVE-2023-39323 and Go issue https://go.dev/issue/63211.
View the release notes for more information:
https://go.dev/doc/devel/release#go1.20.9
go1.19.13 (released 2023-09-06) includes fixes to the go command, and the
crypto/tls and net/http packages. See the Go 1.19.13 milestone on our issue
tracker for details.
This minor releases includes 4 security fixes following the security policy:
- cmd/go: go.mod toolchain directive allows arbitrary execution
The go.mod toolchain directive, introduced in Go 1.21, could be leveraged to
execute scripts and binaries relative to the root of the module when the
"go" command was executed within the module. This applies to modules
downloaded using the "go" command from the module proxy, as well as modules
downloaded directly using VCS software.
Thanks to Juho Nurminen of Mattermost for reporting this issue.
This is CVE-2023-39320 and Go issue https://go.dev/issue/62198.
- html/template: improper handling of HTML-like comments within script
contexts
The html/template package did not properly handle HMTL-like "<!--" and "-->"
comment tokens, nor hashbang "#!" comment tokens, in <script> contexts. This
may cause the template parser to improperly interpret the contents of
<script> contexts, causing actions to be improperly escaped. This could be
leveraged to perform an XSS attack.
Thanks to Takeshi Kaneko (GMO Cybersecurity by Ierae, Inc.) for reporting
this issue.
This is CVE-2023-39318 and Go issue https://go.dev/issue/62196.
- html/template: improper handling of special tags within script contexts
The html/template package did not apply the proper rules for handling
occurrences of "<script", "<!--", and "</script" within JS literals in
<script> contexts. This may cause the template parser to improperly
consider script contexts to be terminated early, causing actions to be
improperly escaped. This could be leveraged to perform an XSS attack.
Thanks to Takeshi Kaneko (GMO Cybersecurity by Ierae, Inc.) for reporting
this issue.
This is CVE-2023-39319 and Go issue https://go.dev/issue/62197.
- crypto/tls: panic when processing post-handshake message on QUIC connections
Processing an incomplete post-handshake message for a QUIC connection caused
a panic.
Thanks to Marten Seemann for reporting this issue.
This is CVE-2023-39321 and CVE-2023-39322 and Go issue
https://go.dev/issue/62266.
This minor releases includes 4 security fixes following the security policy:
- cmd/go: go.mod toolchain directive allows arbitrary execution
The go.mod toolchain directive, introduced in Go 1.21, could be leveraged to
execute scripts and binaries relative to the root of the module when the
"go" command was executed within the module. This applies to modules
downloaded using the "go" command from the module proxy, as well as modules
downloaded directly using VCS software.
Thanks to Juho Nurminen of Mattermost for reporting this issue.
This is CVE-2023-39320 and Go issue https://go.dev/issue/62198.
- html/template: improper handling of HTML-like comments within script
contexts
The html/template package did not properly handle HMTL-like "<!--" and "-->"
comment tokens, nor hashbang "#!" comment tokens, in <script> contexts. This
may cause the template parser to improperly interpret the contents of
<script> contexts, causing actions to be improperly escaped. This could be
leveraged to perform an XSS attack.
Thanks to Takeshi Kaneko (GMO Cybersecurity by Ierae, Inc.) for reporting
this issue.
This is CVE-2023-39318 and Go issue https://go.dev/issue/62196.
- html/template: improper handling of special tags within script contexts
The html/template package did not apply the proper rules for handling
occurrences of "<script", "<!--", and "</script" within JS literals in
<script> contexts. This may cause the template parser to improperly
consider script contexts to be terminated early, causing actions to be
improperly escaped. This could be leveraged to perform an XSS attack.
Thanks to Takeshi Kaneko (GMO Cybersecurity by Ierae, Inc.) for reporting
this issue.
This is CVE-2023-39319 and Go issue https://go.dev/issue/62197.
- crypto/tls: panic when processing post-handshake message on QUIC connections
Processing an incomplete post-handshake message for a QUIC connection caused
a panic.
Thanks to Marten Seemann for reporting this issue.
This is CVE-2023-39321 and CVE-2023-39322 and Go issue
https://go.dev/issue/62266.
View the release notes for more information:
https://go.dev/doc/devel/release#go1.21.1
go1.20.7 (released 2023-08-01) includes a security fix to the crypto/tls
package, as well as bug fixes to the assembler and the compiler. See the Go
1.20.7 milestone on our issue tracker for details.
crypto/tls: restrict RSA keys in certificates to <= 8192 bits
Extremely large RSA keys in certificate chains can cause a client/server
to expend significant CPU time verifying signatures. Limit this by
restricting the size of RSA keys transmitted during handshakes to <=
8192 bits.
Based on a survey of publicly trusted RSA keys, there are currently only
three certificates in circulation with keys larger than this, and all
three appear to be test certificates that are not actively deployed. It
is possible there are larger keys in use in private PKIs, but we target
the web PKI, so causing breakage here in the interests of increasing the
default safety of users of crypto/tls seems reasonable.
Thanks to Mateusz Poliwczak for reporting this issue.
This minor release includes 1 security fix following the security policy:
net/http: insufficient sanitization of Host header
The HTTP/1 client did not fully validate the contents of the Host header. A
maliciously crafted Host header could inject additional headers or entire
requests. The HTTP/1 client now refuses to send requests containing an invalid
Request.Host or Request.URL.Host value.
Thanks to Bartek Nowotarski for reporting this issue.
Includes security fixes for CVE-2023-29406 and Go issue
https://go.dev/issue/60374
This minor release includes 1 security fix following the security policy:
net/http: insufficient sanitization of Host header
The HTTP/1 client did not fully validate the contents of the Host header. A
maliciously crafted Host header could inject additional headers or entire
requests. The HTTP/1 client now refuses to send requests containing an invalid
Request.Host or Request.URL.Host value.
Thanks to Bartek Nowotarski for reporting this issue.
Includes security fixes for CVE-2023-29406 and Go issue
https://go.dev/issue/60374
This minor release includes 3 security fixes following the security policy:
- cmd/go: cgo code injection
The go command may generate unexpected code at build time when using cgo. This
may result in unexpected behavior when running a go program which uses cgo.
This may occur when running an untrusted module which contains directories
with newline characters in their names. Modules which are retrieved using the
go command, i.e. via "go get", are not affected (modules retrieved using
GOPATH-mode, i.e. GO111MODULE=off, may be affected).
Thanks to Juho Nurminen of Mattermost for reporting this issue.
This is CVE-2023-29402 and Go issue https://go.dev/issue/60167.
- runtime: unexpected behavior of setuid/setgid binaries
The Go runtime didn't act any differently when a binary had the setuid/setgid
bit set. On Unix platforms, if a setuid/setgid binary was executed with
standard I/O file descriptors closed, opening any files could result in
unexpected content being read/written with elevated prilieges. Similarly if a
setuid/setgid program was terminated, either via panic or signal, it could
leak the contents of its registers.
Thanks to Vincent Dehors from Synacktiv for reporting this issue.
This is CVE-2023-29403 and Go issue https://go.dev/issue/60272.
- cmd/go: improper sanitization of LDFLAGS
The go command may execute arbitrary code at build time when using cgo. This
may occur when running "go get" on a malicious module, or when running any
other command which builds untrusted code. This is can by triggered by linker
flags, specified via a "#cgo LDFLAGS" directive.
Thanks to Juho Nurminen of Mattermost for reporting this issue.
This is CVE-2023-29404 and CVE-2023-29405 and Go issues
https://go.dev/issue/60305 and https://go.dev/issue/60306.
This minor release includes 3 security fixes following the security policy:
- cmd/go: cgo code injection
The go command may generate unexpected code at build time when using cgo. This
may result in unexpected behavior when running a go program which uses cgo.
This may occur when running an untrusted module which contains directories
with newline characters in their names. Modules which are retrieved using the
go command, i.e. via "go get", are not affected (modules retrieved using
GOPATH-mode, i.e. GO111MODULE=off, may be affected).
Thanks to Juho Nurminen of Mattermost for reporting this issue.
This is CVE-2023-29402 and Go issue https://go.dev/issue/60167.
- runtime: unexpected behavior of setuid/setgid binaries
The Go runtime didn't act any differently when a binary had the setuid/setgid
bit set. On Unix platforms, if a setuid/setgid binary was executed with
standard I/O file descriptors closed, opening any files could result in
unexpected content being read/written with elevated prilieges. Similarly if a
setuid/setgid program was terminated, either via panic or signal, it could
leak the contents of its registers.
Thanks to Vincent Dehors from Synacktiv for reporting this issue.
This is CVE-2023-29403 and Go issue https://go.dev/issue/60272.
- cmd/go: improper sanitization of LDFLAGS
The go command may execute arbitrary code at build time when using cgo. This
may occur when running "go get" on a malicious module, or when running any
other command which builds untrusted code. This is can by triggered by linker
flags, specified via a "#cgo LDFLAGS" directive.
Thanks to Juho Nurminen of Mattermost for reporting this issue.
This is CVE-2023-29404 and CVE-2023-29405 and Go issues
https://go.dev/issue/60305 and https://go.dev/issue/60306.
Almost all uses, if not all of them, are wrong, according to the
semantics of BUILD_DEPENDS (packages built for target available for
use _by_ tools at build-time) and TOOL_DEPEPNDS (packages built for
host available for use _as_ tools at build-time).
No change to BUILD_DEPENDS as used correctly inside buildlink3.
As proposed on tech-pkg:
https://mail-index.netbsd.org/tech-pkg/2023/06/03/msg027632.html
This minor release includes 3 security fixes following the security policy:
* html/template: improper sanitization of CSS values
Angle brackets (<>) were not considered dangerous characters when inserted
into CSS contexts. Templates containing multiple actions separated by a '/'
character could result in unexpectedly closing the CSS context and allowing
for injection of unexpected HMTL, if executed with untrusted input.
Thanks to Juho Nurminen of Mattermost for reporting this issue.
This is CVE-2023-24539 and Go issue https://go.dev/issue/59720.
* html/template: improper handling of JavaScript whitespace
Not all valid JavaScript whitespace characters were considered to be
whitespace. Templates containing whitespace characters outside of the
character set "\t\n\f\r\u0020\u2028\u2029" in JavaScript contexts that also
contain actions may not be properly sanitized during execution.
Thanks to Juho Nurminen of Mattermost for reporting this issue.
This is CVE-2023-24540 and Go issue https://go.dev/issue/59721.
* html/template: improper handling of empty HTML attributes
Templates containing actions in unquoted HTML attributes (e.g. "attr={{.}}")
executed with empty input could result in output that would have unexpected
results when parsed due to HTML normalization rules. This may allow injection
of arbitrary attributes into tags.
Thanks to Juho Nurminen of Mattermost for reporting this issue.
This is CVE-2023-29400 and Go issue https://go.dev/issue/59722.
This minor release includes 3 security fixes following the security policy:
* html/template: improper sanitization of CSS values
Angle brackets (<>) were not considered dangerous characters when inserted
into CSS contexts. Templates containing multiple actions separated by a '/'
character could result in unexpectedly closing the CSS context and allowing
for injection of unexpected HMTL, if executed with untrusted input.
Thanks to Juho Nurminen of Mattermost for reporting this issue.
This is CVE-2023-24539 and Go issue https://go.dev/issue/59720.
* html/template: improper handling of JavaScript whitespace
Not all valid JavaScript whitespace characters were considered to be
whitespace. Templates containing whitespace characters outside of the
character set "\t\n\f\r\u0020\u2028\u2029" in JavaScript contexts that also
contain actions may not be properly sanitized during execution.
Thanks to Juho Nurminen of Mattermost for reporting this issue.
This is CVE-2023-24540 and Go issue https://go.dev/issue/59721.
* html/template: improper handling of empty HTML attributes
Templates containing actions in unquoted HTML attributes (e.g. "attr={{.}}")
executed with empty input could result in output that would have unexpected
results when parsed due to HTML normalization rules. This may allow injection
of arbitrary attributes into tags.
Thanks to Juho Nurminen of Mattermost for reporting this issue.
This is CVE-2023-29400 and Go issue https://go.dev/issue/59722.
This minor release includes 4 security fixes following the security policy:
- go/parser: infinite loop in parsing
Calling any of the Parse functions on Go source code which contains //line
directives with very large line numbers can cause an infinite loop due to
integer overflow.
Thanks to Philippe Antoine (Catena cyber) for reporting this issue.
This is CVE-2023-24537 and Go issue https://go.dev/issue/59180.
- html/template: backticks not treated as string delimiters
Templates did not properly consider backticks (`) as Javascript string
delimiters, and as such did not escape them as expected. Backticks are used,
since ES6, for JS template literals. If a template contained a Go template
action within a Javascript template literal, the contents of the action could
be used to terminate the literal, injecting arbitrary Javascript code into
the Go template.
As ES6 template literals are rather complex, and themselves can do string
interpolation, we've decided to simply disallow Go template actions from
being used inside of them (e.g. "var a = {{.}}"), since there is no obviously
safe way to allow this behavior. This takes the same approach as
github.com/google/safehtml. Template.Parse will now return an Error when it
encounters templates like this, with a currently unexported ErrorCode with a
value of 12. This ErrorCode will be exported in the next major release.
Users who rely on this behavior can re-enable it using the GODEBUG flag
jstmpllitinterp=1, with the caveat that backticks will now be escaped. This
should be used with caution.
Thanks to Sohom Datta, Manipal Institute of Technology, for reporting this
issue.
This is CVE-2023-24538 and Go issue https://go.dev/issue/59234.
- net/http, net/textproto: denial of service from excessive memory allocation
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.
- net/http, net/textproto, mime/multipart: denial of service from excessive resource consumption
Multipart form parsing can consume large amounts of CPU and memory when
processing form inputs containing very large numbers of parts. This stems
from several causes:
mime/multipart.Reader.ReadForm limits the total memory a parsed multipart
form can consume. ReadForm could undercount the amount of memory consumed,
leading it to accept larger inputs than intended. Limiting total memory does
not account for increased pressure on the garbage collector from large
numbers of small allocations in forms with many parts. ReadForm could
allocate a large number of short-lived buffers, further increasing pressure
on the garbage collector. The combination of these factors can permit an
attacker to cause an program that parses multipart forms to consume large
amounts of CPU and memory, potentially resulting in a denial of service. This
affects programs that use mime/multipart.Reader.ReadForm, as well as form
parsing in the net/http package with the Request methods FormFile, FormValue,
ParseMultipartForm, and PostFormValue.
ReadForm now does a better job of estimating the memory consumption of parsed
forms, and performs many fewer short-lived allocations.
In addition, mime/multipart.Reader now imposes the following limits on the
size of parsed forms:
Forms parsed with ReadForm may contain no more than 1000 parts. This limit
may be adjusted with the environment variable GODEBUG=multipartmaxparts=.
Form parts parsed with NextPart and NextRawPart may contain no more than
10,000 header fields. In addition, forms parsed with ReadForm may contain no
more than 10,000 header fields across all parts. This limit may be adjusted
with the environment variable GODEBUG=multipartmaxheaders=. Thanks to Jakob
Ackermann (@das7pad) for discovering this issue.
This is CVE-2023-24536 and Go issue https://go.dev/issue/59153.
This minor release includes 4 security fixes following the security policy:
- go/parser: infinite loop in parsing
Calling any of the Parse functions on Go source code which contains //line
directives with very large line numbers can cause an infinite loop due to
integer overflow.
Thanks to Philippe Antoine (Catena cyber) for reporting this issue.
This is CVE-2023-24537 and Go issue https://go.dev/issue/59180.
- html/template: backticks not treated as string delimiters
Templates did not properly consider backticks (`) as Javascript string
delimiters, and as such did not escape them as expected. Backticks are used,
since ES6, for JS template literals. If a template contained a Go template
action within a Javascript template literal, the contents of the action could
be used to terminate the literal, injecting arbitrary Javascript code into
the Go template.
As ES6 template literals are rather complex, and themselves can do string
interpolation, we've decided to simply disallow Go template actions from
being used inside of them (e.g. "var a = {{.}}"), since there is no obviously
safe way to allow this behavior. This takes the same approach as
github.com/google/safehtml. Template.Parse will now return an Error when it
encounters templates like this, with a currently unexported ErrorCode with a
value of 12. This ErrorCode will be exported in the next major release.
Users who rely on this behavior can re-enable it using the GODEBUG flag
jstmpllitinterp=1, with the caveat that backticks will now be escaped. This
should be used with caution.
Thanks to Sohom Datta, Manipal Institute of Technology, for reporting this
issue.
This is CVE-2023-24538 and Go issue https://go.dev/issue/59234.
- net/http, net/textproto: denial of service from excessive memory allocation
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.
- net/http, net/textproto, mime/multipart: denial of service from excessive resource consumption
Multipart form parsing can consume large amounts of CPU and memory when
processing form inputs containing very large numbers of parts. This stems
from several causes:
mime/multipart.Reader.ReadForm limits the total memory a parsed multipart
form can consume. ReadForm could undercount the amount of memory consumed,
leading it to accept larger inputs than intended. Limiting total memory does
not account for increased pressure on the garbage collector from large
numbers of small allocations in forms with many parts. ReadForm could
allocate a large number of short-lived buffers, further increasing pressure
on the garbage collector. The combination of these factors can permit an
attacker to cause an program that parses multipart forms to consume large
amounts of CPU and memory, potentially resulting in a denial of service. This
affects programs that use mime/multipart.Reader.ReadForm, as well as form
parsing in the net/http package with the Request methods FormFile, FormValue,
ParseMultipartForm, and PostFormValue.
ReadForm now does a better job of estimating the memory consumption of parsed
forms, and performs many fewer short-lived allocations.
In addition, mime/multipart.Reader now imposes the following limits on the
size of parsed forms:
Forms parsed with ReadForm may contain no more than 1000 parts. This limit
may be adjusted with the environment variable GODEBUG=multipartmaxparts=.
Form parts parsed with NextPart and NextRawPart may contain no more than
10,000 header fields. In addition, forms parsed with ReadForm may contain no
more than 10,000 header fields across all parts. This limit may be adjusted
with the environment variable GODEBUG=multipartmaxheaders=. Thanks to Jakob
Ackermann (@das7pad) for discovering this issue.
This is CVE-2023-24536 and Go issue https://go.dev/issue/59153.
This minor release includes 1 security fix following the security policy:
crypto/elliptic: incorrect P-256 ScalarMult and ScalarBaseMult results
The ScalarMult and ScalarBaseMult methods of the P256 Curve may return an
incorrect result if called with some specific unreduced scalars (a scalar larger
than the order of the curve).
This does not impact usages of crypto/ecdsa or crypto/ecdh.
Thanks to Guido Vranken for repoting this issue via the Ethereum Foundation bug
bounty program.
This is CVE-2023-24532 and Go issue https://go.dev/issue/58647.
This minor release includes 1 security fix following the security policy:
crypto/elliptic: incorrect P-256 ScalarMult and ScalarBaseMult results
The ScalarMult and ScalarBaseMult methods of the P256 Curve may return an
incorrect result if called with some specific unreduced scalars (a scalar larger
than the order of the curve).
This does not impact usages of crypto/ecdsa or crypto/ecdh.
Thanks to Guido Vranken for repoting this issue via the Ethereum Foundation bug
bounty program.
This is CVE-2023-24532 and Go issue https://go.dev/issue/58647.
This minor release includes 4 security fixes following the security policy:
- path/filepath: path traversal in filepath.Clean on Windows
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.
Thanks to RyotaK (https://ryotak.net) for reporting this issue.
This is CVE-2022-41722 and Go issue https://go.dev/issue/57274.
- net/http, mime/multipart: denial of service from excessive resource
consumption
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 takes a maxMemory parameter, and is documented as storing "up to
maxMemory bytes +10MB (reserved for non-file parts) in memory". File parts
which cannot be stored in memory are stored on disk in temporary files. The
unconfigurable 10MB reserved for non-file parts is excessively large and can
potentially open a denial of service vector on its own. However, ReadForm did
not properly account for all memory consumed by a parsed form, such as map
entry overhead, part names, and MIME headers, permitting a maliciously
crafted form to consume well over 10MB. In addition, ReadForm contained no
limit on the number of disk files created, permitting a relatively small
request body to create a large number of disk temporary files.
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.
Thanks to Arpad Ryszka and Jakob Ackermann (@das7pad) for reporting this
issue.
This is CVE-2022-41725 and Go issue https://go.dev/issue/58006.
- crypto/tls: large handshake records may cause panics
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).
Thanks to Marten Seemann for reporting this issue.
This is CVE-2022-41724 and Go issue https://go.dev/issue/58001.
- net/http: avoid quadratic complexity in HPACK decoding
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.
Thanks to Philippe Antoine (Catena cyber) for reporting this issue.
This is CVE-2022-41723 and Go issue https://go.dev/issue/57855.
This minor release includes 4 security fixes following the security policy:
- path/filepath: path traversal in filepath.Clean on Windows
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.
Thanks to RyotaK (https://ryotak.net) for reporting this issue.
This is CVE-2022-41722 and Go issue https://go.dev/issue/57274.
- net/http, mime/multipart: denial of service from excessive resource
consumption
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 takes a maxMemory parameter, and is documented as storing "up to
maxMemory bytes +10MB (reserved for non-file parts) in memory". File parts
which cannot be stored in memory are stored on disk in temporary files. The
unconfigurable 10MB reserved for non-file parts is excessively large and can
potentially open a denial of service vector on its own. However, ReadForm did
not properly account for all memory consumed by a parsed form, such as map
entry overhead, part names, and MIME headers, permitting a maliciously
crafted form to consume well over 10MB. In addition, ReadForm contained no
limit on the number of disk files created, permitting a relatively small
request body to create a large number of disk temporary files.
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.
Thanks to Arpad Ryszka and Jakob Ackermann (@das7pad) for reporting this
issue.
This is CVE-2022-41725 and Go issue https://go.dev/issue/58006.
- crypto/tls: large handshake records may cause panics
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).
Thanks to Marten Seemann for reporting this issue.
This is CVE-2022-41724 and Go issue https://go.dev/issue/58001.
- net/http: avoid quadratic complexity in HPACK decoding
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.
Thanks to Philippe Antoine (Catena cyber) for reporting this issue.
This is CVE-2022-41723 and Go issue https://go.dev/issue/57855.
The latest Go release, version 1.20, arrives six months after Go 1.19. Most of
its changes are in the implementation of the toolchain, runtime, and libraries.
As always, the release maintains the Go 1 promise of compatibility. We expect
almost all Go programs to continue to compile and run as before.
https://go.dev/doc/go1.20
go1.19.5 (released 2023-01-10) includes fixes to the compiler, the linker, and
the crypto/x509, net/http, sync/atomic, and syscall packages. See the Go 1.19.5
milestone on our issue tracker for details.
go1.18.10 (released 2023-01-10) includes fixes to cgo, the compiler, the
linker, and the crypto/x509, net/http, and syscall packages. See the Go 1.18.10
milestone on our issue tracker for details.
While here, clean up obsolete Go versions in version.mk.
This minor release includes 2 security fixes following the security policy
<https://go.dev/security>:
- os, net/http: avoid escapes from os.DirFS and http.Dir on Windows
The os.DirFS function and http.Dir type provide access to a tree of files
rooted at a given directory. These functions permitted access to Windows
device files under that root. For example, os.DirFS("C:/tmp").Open("COM1")
would open the COM1 device. Both os.DirFS and http.Dir only provide
read-only filesystem access.
In addition, on Windows, an os.DirFS for the directory \ (the root of the
current drive) can permit a maliciously crafted path to escape from the drive
and access any path on the system.
The behavior of os.DirFS("") has changed. Previously, an empty root was
treated equivalently to "/", so os.DirFS("").Open("tmp") would open the path
"/tmp". This now returns an error.
This is CVE-2022-41720 and Go issue https://go.dev/issue/56694.
- net/http: limit canonical header cache by bytes, not entries
An attacker can cause excessive memory growth in a Go server accepting HTTP/2
requests.
HTTP/2 server connections contain a cache of HTTP header keys sent by the
client. While the total number of entries in this cache is capped, an
attacker sending very large keys can cause the server to allocate
approximately 64 MiB per open connection.
This issue is also fixed in golang.org/x/net/http2, for users manually
configuring HTTP/2.
Thanks to Josselin Costanzi for reporting this issue.
This is CVE-2022-41717 and Go issue https://go.dev/issue/56350.
This minor release includes 2 security fixes following the security policy
<https://go.dev/security>:
- os, net/http: avoid escapes from os.DirFS and http.Dir on Windows
The os.DirFS function and http.Dir type provide access to a tree of files
rooted at a given directory. These functions permitted access to Windows
device files under that root. For example, os.DirFS("C:/tmp").Open("COM1")
would open the COM1 device. Both os.DirFS and http.Dir only provide
read-only filesystem access.
In addition, on Windows, an os.DirFS for the directory \ (the root of the
current drive) can permit a maliciously crafted path to escape from the drive
and access any path on the system.
The behavior of os.DirFS("") has changed. Previously, an empty root was
treated equivalently to "/", so os.DirFS("").Open("tmp") would open the path
"/tmp". This now returns an error.
This is CVE-2022-41720 and Go issue https://go.dev/issue/56694.
- net/http: limit canonical header cache by bytes, not entries
An attacker can cause excessive memory growth in a Go server accepting HTTP/2
requests.
HTTP/2 server connections contain a cache of HTTP header keys sent by the
client. While the total number of entries in this cache is capped, an
attacker sending very large keys can cause the server to allocate
approximately 64 MiB per open connection.
This issue is also fixed in golang.org/x/net/http2, for users manually
configuring HTTP/2.
Thanks to Josselin Costanzi for reporting this issue.
This is CVE-2022-41717 and Go issue https://go.dev/issue/56350.
This release includes 1 security fixes following the security policy:
syscall, os/exec: unsanitized NUL in environment variables
On Windows, syscall.StartProcess and os/exec.Cmd did not properly check for
invalid environment variable values. A malicious environment variable value
could exploit this behavior to set a value for a different environment
variable. For example, the environment variable string "A=B\x00C=D" set the
variables "A=B" and "C=D".
Thanks to RyotaK (https://twitter.com/ryotkak) for reporting this issue.
This is CVE-2022-41716 and Go issue https://go.dev/issue/56284.
View the release notes for more information:
https://go.dev/doc/devel/release#go1.19.3
This release includes 1 security fixes following the security policy:
syscall, os/exec: unsanitized NUL in environment variables
On Windows, syscall.StartProcess and os/exec.Cmd did not properly check for
invalid environment variable values. A malicious environment variable value
could exploit this behavior to set a value for a different environment
variable. For example, the environment variable string "A=B\x00C=D" set the
variables "A=B" and "C=D".
Thanks to RyotaK (https://twitter.com/ryotkak) for reporting this issue.
This is CVE-2022-41716 and Go issue https://go.dev/issue/56284.
View the release notes for more information:
https://go.dev/doc/devel/release#go1.18.8
This minor release includes 3 security fixes following the security policy:
- archive/tar: unbounded memory consumption when reading headers
Reader.Read did not set a limit on the maximum size of file headers.
A maliciously crafted archive could cause Read to allocate unbounded
amounts of memory, potentially causing resource exhaustion or panics.
Reader.Read now limits the maximum size of header blocks to 1 MiB.
Thanks to Adam Korczynski (ADA Logics) and OSS-Fuzz for reporting this issue.
This is CVE-2022-2879 and Go issue https://go.dev/issue/54853.
- net/http/httputil: ReverseProxy should not forward unparseable query parameters
Requests forwarded by ReverseProxy included the raw query parameters from the
inbound request, including unparseable parameters rejected by net/http. This
could permit query parameter smuggling when a Go proxy forwards a parameter
with an unparseable value.
ReverseProxy will now sanitize the query parameters in the forwarded query
when the outbound request's Form field is set after the ReverseProxy.Director
function returns, indicating that the proxy has parsed the query parameters.
Proxies which do not parse query parameters continue to forward the original
query parameters unchanged.
Thanks to Gal Goldstein (Security Researcher, Oxeye) and
Daniel Abeles (Head of Research, Oxeye) for reporting this issue.
This is CVE-2022-2880 and Go issue https://go.dev/issue/54663.
- regexp/syntax: limit memory used by parsing regexps
The parsed regexp representation is linear in the size of the input,
but in some cases the constant factor can be as high as 40,000,
making relatively small regexps consume much larger amounts of memory.
Each regexp being parsed is now limited to a 256 MB memory footprint.
Regular expressions whose representation would use more space than that
are now rejected. Normal use of regular expressions is unaffected.
Thanks to Adam Korczynski (ADA Logics) and OSS-Fuzz for reporting this issue.
This is CVE-2022-41715 and Go issue https://go.dev/issue/55949.
This minor release includes 3 security fixes following the security policy:
- archive/tar: unbounded memory consumption when reading headers
Reader.Read did not set a limit on the maximum size of file headers.
A maliciously crafted archive could cause Read to allocate unbounded
amounts of memory, potentially causing resource exhaustion or panics.
Reader.Read now limits the maximum size of header blocks to 1 MiB.
Thanks to Adam Korczynski (ADA Logics) and OSS-Fuzz for reporting this issue.
This is CVE-2022-2879 and Go issue https://go.dev/issue/54853.
- net/http/httputil: ReverseProxy should not forward unparseable query parameters
Requests forwarded by ReverseProxy included the raw query parameters from the
inbound request, including unparseable parameters rejected by net/http. This
could permit query parameter smuggling when a Go proxy forwards a parameter
with an unparseable value.
ReverseProxy will now sanitize the query parameters in the forwarded query
when the outbound request's Form field is set after the ReverseProxy.Director
function returns, indicating that the proxy has parsed the query parameters.
Proxies which do not parse query parameters continue to forward the original
query parameters unchanged.
Thanks to Gal Goldstein (Security Researcher, Oxeye) and
Daniel Abeles (Head of Research, Oxeye) for reporting this issue.
This is CVE-2022-2880 and Go issue https://go.dev/issue/54663.
- regexp/syntax: limit memory used by parsing regexps
The parsed regexp representation is linear in the size of the input,
but in some cases the constant factor can be as high as 40,000,
making relatively small regexps consume much larger amounts of memory.
Each regexp being parsed is now limited to a 256 MB memory footprint.
Regular expressions whose representation would use more space than that
are now rejected. Normal use of regular expressions is unaffected.
Thanks to Adam Korczynski (ADA Logics) and OSS-Fuzz for reporting this issue.
This is CVE-2022-41715 and Go issue https://go.dev/issue/55949.
The previous default (...) means "build the whole world", which is never
what you want. Instead, use "./...", which means "everything below the
top-level directory". According to the documentation, this is what was
meant the whole time.
This is probably a no-op because any useful Go package overrides this
currently.
no objection from wiz@
Fixes builds of go118 and newer in x86_64 chroots on an arm64 host. The go
build system parses "uname -v" and incorrectly assumes that if you're running
on an arm64 host you always want arm64 binaries.
This minor release includes 2 security fixes following the security policy:
net/http: handle server errors after sending GOAWAY
A closing HTTP/2 server connection could hang forever waiting for a clean
shutdown that was preempted by a subsequent fatal error. This failure mode
could be exploited to cause a denial of service.
Thanks to Bahruz Jabiyev, Tommaso Innocenti, Anthony Gavazzi, Steven Sprecher,
and Kaan Onarlioglu for reporting this.
This is CVE-2022-27664 and Go issue https://go.dev/issue/54658.
net/url: JoinPath does not strip relative path components in all circumstances
JoinPath and URL.JoinPath would not remove ../ path components appended to a
relative path. For example, JoinPath("https://go.dev", "../go") returned the
URL https://go.dev/../go, despite the JoinPath documentation stating that ../
path elements are cleaned from the result.
Thanks to q0jt for reporting this issue.
This is CVE-2022-32190 and Go issue https://go.dev/issue/54385.
This minor release includes 2 security fixes following the security policy:
net/http: handle server errors after sending GOAWAY
A closing HTTP/2 server connection could hang forever waiting for a clean
shutdown that was preempted by a subsequent fatal error. This failure mode
could be exploited to cause a denial of service.
Thanks to Bahruz Jabiyev, Tommaso Innocenti, Anthony Gavazzi, Steven Sprecher,
and Kaan Onarlioglu for reporting this.
This is CVE-2022-27664 and Go issue https://go.dev/issue/54658.
net/url: JoinPath does not strip relative path components in all circumstances
JoinPath and URL.JoinPath would not remove ../ path components appended to a
relative path. For example, JoinPath("https://go.dev", "../go") returned the
URL https://go.dev/../go, despite the JoinPath documentation stating that ../
path elements are cleaned from the result.
Thanks to q0jt for reporting this issue.
This is CVE-2022-32190 and Go issue https://go.dev/issue/54385.
1 security fix following the security policy:
encoding/gob & math/big: decoding big.Float and big.Rat can panic
Decoding big.Float and big.Rat types can panic if the encoded message is too
short.
This is CVE-2022-32189 and Go issue https://go.dev/issue/53871.
1 security fix following the security policy:
encoding/gob & math/big: decoding big.Float and big.Rat can panic
Decoding big.Float and big.Rat types can panic if the encoded message is too
short.
This is CVE-2022-32189 and Go issue https://go.dev/issue/53871.
This minor release includes 9 security fixes following the security policy:
net/http: improper sanitization of Transfer-Encoding header
The HTTP/1 client accepted some invalid Transfer-Encoding headers as indicating
a "chunked" encoding. This could potentially allow for request smuggling, but
only if combined with an intermediate server that also improperly failed to
reject the header as invalid.
This is CVE-2022-1705 and https://go.dev/issue/53188.
When httputil.ReverseProxy.ServeHTTP was called with a Request.Header map
containing a nil value for the X-Forwarded-For header, ReverseProxy would set
the client IP as the value of the X-Forwarded-For header, contrary to its
documentation. In the more usual case where a Director function set the
X-Forwarded-For header value to nil, ReverseProxy would leave the header
unmodified as expected.
This is https://go.dev/issue/53423 and CVE-2022-32148.
Thanks to Christian Mehlmauer for reporting this issue.
compress/gzip: stack exhaustion in Reader.Read
Calling Reader.Read on an archive containing a large number of concatenated
0-length compressed files can cause a panic due to stack exhaustion.
This is CVE-2022-30631 and Go issue https://go.dev/issue/53168.
encoding/xml: stack exhaustion in Unmarshal
Calling Unmarshal on a XML document into a Go struct which has a nested field
that uses the any field tag can cause a panic due to stack exhaustion.
This is CVE-2022-30633 and Go issue https://go.dev/issue/53611.
encoding/xml: stack exhaustion in Decoder.Skip
Calling Decoder.Skip when parsing a deeply nested XML document can cause a
panic due to stack exhaustion.
The Go Security team discovered this issue, and it was independently reported
by Juho Nurminen of Mattermost.
This is CVE-2022-28131 and Go issue https://go.dev/issue/53614.
encoding/gob: stack exhaustion in Decoder.Decode
Calling Decoder.Decode on a message which contains deeply nested structures can
cause a panic due to stack exhaustion.
This is CVE-2022-30635 and Go issue https://go.dev/issue/53615.
path/filepath: stack exhaustion in Glob
Calling Glob on a path which contains a large number of path separators can
cause a panic due to stack exhaustion.
Thanks to Juho Nurminen of Mattermost for reporting this issue.
This is CVE-2022-30632 and Go issue https://go.dev/issue/53416.
io/fs: stack exhaustion in Glob
Calling Glob on a path which contains a large number of path separators can
cause a panic due to stack exhaustion.
This is CVE-2022-30630 and Go issue https://go.dev/issue/53415.
go/parser: stack exhaustion in all Parse* functions
Calling any of the Parse functions on Go source code which contains deeply
nested types or declarations can cause a panic due to stack exhaustion.
Thanks to Juho Nurminen of Mattermost for reporting this issue.
This is CVE-2022-1962 and Go issue https://go.dev/issue/53616.
This minor release includes 9 security fixes following the security policy:
net/http: improper sanitization of Transfer-Encoding header
The HTTP/1 client accepted some invalid Transfer-Encoding headers as indicating
a "chunked" encoding. This could potentially allow for request smuggling, but
only if combined with an intermediate server that also improperly failed to
reject the header as invalid.
This is CVE-2022-1705 and https://go.dev/issue/53188.
When httputil.ReverseProxy.ServeHTTP was called with a Request.Header map
containing a nil value for the X-Forwarded-For header, ReverseProxy would set
the client IP as the value of the X-Forwarded-For header, contrary to its
documentation. In the more usual case where a Director function set the
X-Forwarded-For header value to nil, ReverseProxy would leave the header
unmodified as expected.
This is https://go.dev/issue/53423 and CVE-2022-32148.
Thanks to Christian Mehlmauer for reporting this issue.
compress/gzip: stack exhaustion in Reader.Read
Calling Reader.Read on an archive containing a large number of concatenated
0-length compressed files can cause a panic due to stack exhaustion.
This is CVE-2022-30631 and Go issue https://go.dev/issue/53168.
encoding/xml: stack exhaustion in Unmarshal
Calling Unmarshal on a XML document into a Go struct which has a nested field
that uses the any field tag can cause a panic due to stack exhaustion.
This is CVE-2022-30633 and Go issue https://go.dev/issue/53611.
encoding/xml: stack exhaustion in Decoder.Skip
Calling Decoder.Skip when parsing a deeply nested XML document can cause a
panic due to stack exhaustion.
The Go Security team discovered this issue, and it was independently reported
by Juho Nurminen of Mattermost.
This is CVE-2022-28131 and Go issue https://go.dev/issue/53614.
encoding/gob: stack exhaustion in Decoder.Decode
Calling Decoder.Decode on a message which contains deeply nested structures can
cause a panic due to stack exhaustion.
This is CVE-2022-30635 and Go issue https://go.dev/issue/53615.
path/filepath: stack exhaustion in Glob
Calling Glob on a path which contains a large number of path separators can
cause a panic due to stack exhaustion.
Thanks to Juho Nurminen of Mattermost for reporting this issue.
This is CVE-2022-30632 and Go issue https://go.dev/issue/53416.
io/fs: stack exhaustion in Glob
Calling Glob on a path which contains a large number of path separators can
cause a panic due to stack exhaustion.
This is CVE-2022-30630 and Go issue https://go.dev/issue/53415.
go/parser: stack exhaustion in all Parse* functions
Calling any of the Parse functions on Go source code which contains deeply
nested types or declarations can cause a panic due to stack exhaustion.
Thanks to Juho Nurminen of Mattermost for reporting this issue.
This is CVE-2022-1962 and Go issue https://go.dev/issue/53616.
This minor release includes 4 security fixes following the security policy
<https://go.dev/security>:
- crypto/rand: rand.Read hangs with extremely large buffers
On Windows, rand.Read will hang indefinitely if passed a buffer larger
than 1 << 32 - 1 bytes.
Thanks to Davis Goodin and Quim Muntal, working at Microsoft on the Go
toolset, for reporting this issue.
This is CVE-2022-30634 and Go issue https://go.dev/issue/52561.
- crypto/tls: session tickets lack random ticket_age_add
Session tickets generated by crypto/tls did not contain a randomly
generated ticket_age_add. This allows an attacker that can observe TLS
handshakes to correlate successive connections by comparing ticket ages
during session resumption.
Thanks to GitHub user @nervuri for reporting this.
This is CVE-2022-30629 and Go issue https://go.dev/issue/52814.
- os/exec: empty Cmd.Path can result in running unintended binary on
Windows
If, on Windows, Cmd.Run, cmd.Start, cmd.Output, or cmd.CombinedOutput
are executed when Cmd.Path is unset and, in the working directory, there
are binaries named either "..com" or "..exe", they will be executed.
Thanks to Chris Darroch (chrisd8088@github.com), brian m. carlson (
bk2204@github.com), and Mikhail Shcherbakov (https://twitter.com/yu5k3)
for reporting this.
This is CVE-2022-30580 and Go issue https://go.dev/issue/52574.
- path/filepath: Clean(`.\c:`) returns `c:` on Windows
On Windows, the filepath.Clean function could convert an invalid path to
a valid, absolute path. For example, Clean(`.\c:`) returned `c:`.
Thanks to Unrud for reporting this issue.
This is CVE-2022-29804 and Go issue https://go.dev/issue/52476.
This minor release includes 4 security fixes following the security policy
<https://go.dev/security>:
- crypto/rand: rand.Read hangs with extremely large buffers
On Windows, rand.Read will hang indefinitely if passed a buffer larger
than 1 << 32 - 1 bytes.
Thanks to Davis Goodin and Quim Muntal, working at Microsoft on the Go
toolset, for reporting this issue.
This is CVE-2022-30634 and Go issue https://go.dev/issue/52561.
- crypto/tls: session tickets lack random ticket_age_add
Session tickets generated by crypto/tls did not contain a randomly
generated ticket_age_add. This allows an attacker that can observe TLS
handshakes to correlate successive connections by comparing ticket ages
during session resumption.
Thanks to GitHub user @nervuri for reporting this.
This is CVE-2022-30629 and Go issue https://go.dev/issue/52814.
- os/exec: empty Cmd.Path can result in running unintended binary on
Windows
If, on Windows, Cmd.Run, cmd.Start, cmd.Output, or cmd.CombinedOutput
are executed when Cmd.Path is unset and, in the working directory, there
are binaries named either "..com" or "..exe", they will be executed.
Thanks to Chris Darroch (chrisd8088@github.com), brian m. carlson (
bk2204@github.com), and Mikhail Shcherbakov (https://twitter.com/yu5k3)
for reporting this.
This is CVE-2022-30580 and Go issue https://go.dev/issue/52574.
- path/filepath: Clean(`.\c:`) returns `c:` on Windows
On Windows, the filepath.Clean function could convert an invalid path to
a valid, absolute path. For example, Clean(`.\c:`) returned `c:`.
Thanks to Unrud for reporting this issue.
This is CVE-2022-29804 and Go issue https://go.dev/issue/52476.
