VuXML ID | Description |
742279d6-bdbe-11ed-a179-2b68e9d12706 | go -- crypto/elliptic: incorrect P-256 ScalarMult and ScalarBaseMult results
The Go project reports:
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).
Discovery 2023-02-22 Entry 2023-03-08 go119
< 1.19.7
go120
< 1.20.2
CVE-2023-24532
https://groups.google.com/g/golang-dev/c/3wmx8i5WvNY/m/AEOlccrGAwAJ
|
6f5192f5-75a7-11ed-83c0-411d43ce7fe4 | go -- multiple vulnerabilities
The Go project reports:
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.
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.
Discovery 2022-10-20 Entry 2022-12-06 go118
< 1.18.9
go119
< 1.19.4
CVE-2022-41720
CVE-2022-41717
https://groups.google.com/g/golang-dev/c/G9Jj4cO4Gpk/m/kOkLVG6TAgAJ
|
348ee234-d541-11ed-ad86-a134a566f1e6 | go -- multiple vulnerabilities
The Go project reports:
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.
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.
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.
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=.
Discovery 2023-04-04 Entry 2023-04-07 go119
< 1.19.8
go120
< 1.20.3
CVE-2023-24537
CVE-2023-24538
CVE-2023-24534
CVE-2023-24536
https://groups.google.com/g/golang-dev/c/P-sOFU28bj0/m/QE_cqf22AgAJ
|
3d73e384-ad1f-11ed-983c-83fe35862e3a | go -- multiple vulnerabilities
The Go project reports:
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.
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.
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.
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.
Discovery 2023-02-14 Entry 2023-02-15 go119
< 1.19.6
go120
< 1.20.1
CVE-2022-41722
CVE-2022-41725
CVE-2022-41724
CVE-2022-41723
https://groups.google.com/g/golang-dev/c/G2APtTxT1HQ/m/6O6aksDaBAAJ
|
78f2e491-312d-11ee-85f2-bd89b893fcb4 | go -- multiple vulnerabilities
The Go project reports:
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.
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.
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.
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.
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.
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.
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.
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.
Discovery 2023-04-27 Entry 2023-08-02 go119
< 1.19.12
go120
< 1.20.7
CVE-2023-29406
CVE-2023-29402
CVE-2023-29403
CVE-2023-29404
CVE-2023-24539
CVE-2023-24540
CVE-2023-29400
https://groups.google.com/u/1/g/golang-announce/c/X0b6CsSAaYI
https://groups.google.com/u/1/g/golang-announce/c/2q13H6LEEx0
https://groups.google.com/u/1/g/golang-announce/c/q5135a9d924
https://groups.google.com/u/1/g/golang-announce/c/MEb0UyuSMsU
|
26b1100a-5a27-11ed-abfe-29ac76ec31b5 | go -- syscall, os/exec: unsanitized NUL in environment variables
The Go project reports:
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".
Discovery 2022-10-17 Entry 2022-11-01 go118
< 1.18.8
go119
< 1.19.3
CVE-2022-41716
https://groups.google.com/g/golang-dev/c/83nKqv2W1Dk/m/gEJdD5vjDwAJ
|
854c2afb-4424-11ed-af97-adcabf310f9b | go -- multiple vulnerabilities
The Go project reports:
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.
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.
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.
Discovery 2022-10-04 Entry 2022-10-04 go118
< 1.18.7
go119
< 1.19.2
CVE-2022-2879
CVE-2022-2880
CVE-2022-41715
https://groups.google.com/g/golang-announce/c/xtuG5faxtaU/m/jEhlI_5WBgAJ
|
6fea7103-2ea4-11ed-b403-3dae8ac60d3e | go -- multiple vulnerabilities
The Go project reports:
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.
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.
Discovery 2022-09-06 Entry 2022-09-07 go118
< 1.18.6
go119
< 1.19.1
CVE-2022-27664
CVE-2022-32190
https://groups.google.com/g/golang-announce/c/x49AQzIVX-s/m/0tgO0pjiBQAJ
|