Backticks not treated as string delimiters in html/template
Impact A malicious peer can use large RSA keys to run a resource exhaustion attack & force a node to spend time doing signature verification of the large key. This vulnerability is present in the core/crypto module of go-libp2p and can occur during the Noise handshake and the libp2p x509 extension verification step. To prevent this attack, go-libp2p now restricts RSA keys to <= 8192 bits.
Patches Users should upgrade their go-libp2p versions to >=v0.27.8, >= v0.28.2, or >=v0.29.1 To protect your application, it's necessary to update to these patch releases AND to use the updated Go compiler (1.20.7 or 1.19.12, respectively)
Workarounds There are no known workarounds
References The Golang crypto/tls package also had this vulnerability ("verifying certificate chains containing large RSA keys is slow” https://github.com/golang/go/issues/61460) Fix in golang/go crypto/tls: https://github.com/golang/go/commit/2350afd2e8ab054390e284c95d5b089c142db017 Fix in quic-go https://github.com/quic-go/quic-go/pull/4012
Angle brackets (<>) are not considered dangerous characters when inserted into CSS contexts. Templates containing multiple actions separated by a '/' character can result in unexpectedly closing the CSS context and allowing for injection of unexpected HTML, if executed with untrusted input.
Golang Go is vulnerable to a denial of service, caused by a flaw when processing large TLS handshake records. By sending specially-crafted TLS handshake records, a remote authenticated attacker could exploit this vulnerability to cause a denial of service condition.
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 by 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.
With the fix applied, HTTP/2 servers now bound the number of simultaneously executing handler goroutines to the stream concurrency limit (MaxConcurrentStreams). 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 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.
Incorrect calculation on P256 curves in crypto/internal/nistec
Go is vulnerable to HTML injection. A remote attacker could inject malicious HTML code into a template containing whitespace characters outside of the character set "\t\n\f\r\u0020\u2028\u2029", which when viewed, would execute in the victim's Web browser within the security context of the hosting site.
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.
A denial of service is possible from excessive resource consumption in net/http and mime/multipart. 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. With fix, 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. In addition, 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.
Golang Go could allow a local authenticated attacker to gain elevated privileges on the system, caused by a flaw when a binary is run with the setuid/setgid bits. By sending a specially crafted request, an authenticated attacker could exploit this vulnerability to gain elevated privileges. to read or write contents of the registers.
Extremely large RSA keys in certificate chains can cause a client/server to expend significant CPU time verifying signatures. With fix, the size of RSA keys transmitted during handshakes is restricted 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.
Excessive memory allocation in net/http and net/textproto
Golang Go could allow a remote attacker to execute arbitrary code on the system, caused by a flaw when running "go get" on a malicious module. By sending a specially crafted request using linker flags, an attacker could exploit this vulnerability to execute arbitrary code on the system.
Golang Go is vulnerable to HTML injection. A remote attacker could inject malicious HTML code into the templates, which when parsed, would execute in the victim's Web browser within the security context of the hosting site.
Insufficient sanitization of Host header in net/http
Excessive resource consumption in net/http, net/textproto and mime/multipart
A flaw was found in golang. 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 requests.
A flaw was found in Go, where it could allow a remote attacker to traverse directories on the system, caused by improper validation of user requests by the filepath.Clean on Windows package. This flaw allows an attacker to send a specially-crafted URL request containing "dot dot" sequences (/../) to view arbitrary files on the system.
Golang Go could allow a remote attacker to execute arbitrary code on the system, caused by a flaw when running "go get" on a malicious module. By sending a specially crafted request using linker flags, an attacker could exploit this vulnerability to execute arbitrary code on the system.
Code injection via go command with cgo in cmd/go