The HTTP client drops sensitive headers after following a cross-domain redirect.
For example, a request to a.com/ containing an Authorization header which is redirected to
b.com/ will not send that header to b.com. In the event that the client received a subsequent
same-domain redirect, however, the sensitive headers would be restored. For example, a chain
of redirects from a.com/, to b.com/1, and finally to b.com/2 would incorrectly send the
Authorization header to b.com/2.
Reference:
https://nvd.nist.gov/vuln/detail/CVE-2024-45336
Upstream-patch:
b72d56f98d
(From OE-Core rev: 63e84b64f055ad7c91de67194e6739c96fb95496)
Signed-off-by: Praveen Kumar <praveen.kumar@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
The archive/zip package's handling of certain types of invalid zip files
differs from the behavior of most zip implementations. This misalignment
could be exploited to create an zip file with contents that vary depending
on the implementation reading the file. The archive/zip package now rejects
files containing these errors.
References:
https://nvd.nist.gov/vuln/detail/CVE-2024-24789
Upstream-patch:
c8e40338cf
(From OE-Core rev: f198fdc392c6e3b99431383ab6577749e83f1cb3)
Signed-off-by: Soumya Sambu <soumya.sambu@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
The original CVE-2023-29406.patch is not complete, causing docker
failures at runtime, backport a complementary fix from golang upstream.
(From OE-Core rev: 973901530c98bc3f1b10d8bb89d55decf6848713)
Signed-off-by: Ming Liu <liu.ming50@gmail.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
CVE-2023-45285:
Using go get to fetch a module with the ".git" suffix may unexpectedly
fallback to the insecure "git://" protocol if the module is unavailable
via the secure "https://" and "git+ssh://" protocols, even if GOINSECURE
is not set for said module. This only affects users who are not using
the module proxy and are fetching modules directly (i.e. GOPROXY=off).
CVE-2023-45287:
Before Go 1.20, the RSA based TLS key exchanges used the math/big
library, which is not constant time. RSA blinding was applied to prevent
timing attacks, but analysis shows this may not have been fully effective.
In particular it appears as if the removal of PKCS#1 padding may leak
timing information, which in turn could be used to recover session key
bits. In Go 1.20, the crypto/tls library switched to a fully constant
time RSA implementation, which we do not believe exhibits any timing
side channels.
References:
https://nvd.nist.gov/vuln/detail/CVE-2023-45285https://nvd.nist.gov/vuln/detail/CVE-2023-45287https://security-tracker.debian.org/tracker/CVE-2023-45285https://security-tracker.debian.org/tracker/CVE-2023-45287
(From OE-Core rev: 616857b9918e8d2e576239b3db2f9f077d1a7222)
Signed-off-by: Soumya Sambu <soumya.sambu@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
A malicious HTTP sender can use chunk extensions to cause a receiver
reading from a request or response body to read many more bytes from
the network than are in the body. A malicious HTTP client can further
exploit this to cause a server to automatically read a large amount
of data (up to about 1GiB) when a handler fails to read the entire
body of a request. Chunk extensions are a little-used HTTP feature
which permit including additional metadata in a request or response
body sent using the chunked encoding. The net/http chunked encoding
reader discards this metadata. A sender can exploit this by inserting
a large metadata segment with each byte transferred. The chunk reader
now produces an error if the ratio of real body to encoded bytes grows
too small.
References:
https://nvd.nist.gov/vuln/detail/CVE-2023-39326https://security-tracker.debian.org/tracker/CVE-2023-39326
(From OE-Core rev: 448df3bb9277287dd8586987199223b7314fdd01)
Signed-off-by: Soumya Sambu <soumya.sambu@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
This change adds a patch that is a partial backport of an upstream
commit[1].
It fixes a bug in go's DNS resolver that was causing a docker issue
where the first "docker pull" always fails after system boot if docker
daemon is started before networking is completely up.
[1] d52883f443
(From OE-Core rev: 8c8b01e84844a7e721c668d5ffbc7161e67f0862)
Signed-off-by: Chaitanya Vadrevu <chaitanya.vadrevu@ni.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
These CVEs affect path handling on Windows.
(From OE-Core rev: 60f75fd6a671fcbfeefb634fe88f6faa17b446b7)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
The html/template package does 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.
References:
https://nvd.nist.gov/vuln/detail/CVE-2023-39319
(From OE-Core rev: afdc322ecff4cfd8478c89a03f7fce748a132b48)
Signed-off-by: Soumya Sambu <soumya.sambu@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
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.
References:
https://nvd.nist.gov/vuln/detail/CVE-2023-29409
(From OE-Core rev: 51c2fee0e4bb4b3131c61d91510394cd4b4f9eb9)
Signed-off-by: Soumya Sambu <soumya.sambu@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
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).
References:
https://nvd.nist.gov/vuln/detail/CVE-2023-29402
Upstream patches:
4dae3bbe0e
(From OE-Core rev: aeb0829e52c60a77a2135af8332435b6e2db5b3d)
Signed-off-by: Archana Polampalli <archana.polampalli@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
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. Flags containing
embedded spaces are mishandled, allowing disallowed flags to be smuggled
through the LDFLAGS sanitization by including them in the argument of
another flag. This only affects usage of the gccgo compiler.
References:
https://nvd.nist.gov/vuln/detail/CVE-2023-29405
Upstream patches:
6d8af00a63
(From OE-Core rev: 7ce6d0029effc06cff500271a124150f1a7db7b3)
Signed-off-by: Archana Polampalli <archana.polampalli@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
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. The arguments for a
number of flags which are non-optional are incorrectly considered optional,
allowing disallowed flags to be smuggled through the LDFLAGS sanitization.
This affects usage of both the gc and gccgo compilers.
References:
https://nvd.nist.gov/vuln/detail/CVE-2023-29404
Upstream patches:
bbeb55f5fa
(From OE-Core rev: 3e51122f8e2b4a7cd2a1c711175e6daf59b8368b)
Signed-off-by: Archana Polampalli <archana.polampalli@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Angle brackets should not appear in CSS contexts, as they may affect
token boundaries (such as closing a <style> tag, resulting in
injection). Instead emit filterFailsafe, matching the behavior for other
dangerous characters.
Thanks to Juho Nurminen of Mattermost for reporting this issue.
For #59720Fixes#59811
Fixes CVE-2023-24539
(From OE-Core rev: 0a09194f3d4ad98d0cf0d070ec0c99e7a6c8a158)
Signed-off-by: Vivek Kumbhar <vkumbhar@mvista.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
A parsed MIME header is a map[string][]string. In the common case,
a header contains many one-element []string slices. To avoid
allocating a separate slice for each key, ReadMIMEHeader looks
ahead in the input to predict the number of keys that will be
parsed, and allocates a single []string of that length.
The individual slices are then allocated out of the larger one.
The prediction of the number of header keys was done by counting
newlines in the input buffer, which does not take into account
header continuation lines (where a header key/value spans multiple
lines) or the end of the header block and the start of the body.
This could lead to a substantial amount of overallocation, for
example when the body consists of nothing but a large block of
newlines.
Fix header key count prediction to take into account the end of
the headers (indicated by a blank line) and continuation lines
(starting with whitespace).
Thanks to Jakob Ackermann (@das7pad) for reporting this issue.
Fixes CVE-2023-24534
For #58975Fixes#59267
(From OE-Core rev: 28bfa033ce965d7316a8b4296d10f3ad74d711db)
Signed-off-by: Vivek Kumbhar <vkumbhar@mvista.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Setting a large line or column number using a //line directive can cause
integer overflow even in small source files.
Limit line and column numbers in //line directives to 2^30-1, which
is small enough to avoid int32 overflow on all reasonbly-sized files.
Fixes CVE-2023-24537
Fixes#59273
For #59180
(From OE-Core rev: 15c07dff384ce4fb0e90f4f32c182a82101a1c82)
Signed-off-by: Vivek Kumbhar <vkumbhar@mvista.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
This CVE is specific to Microsoft Windows, ignore it.
Patch fixing it (https://go-review.googlesource.com/c/go/+/446916)
also adds a redundant check to generic os/exec which
could be backported but it should not be necessary as
backport always takes a small risk to break old code.
(From OE-Core rev: ae8167754ff1c02f2d92af03de804754ea77a3e5)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
path/filepath: do not Clean("a/../c:/b") into c:\b on Windows
Backport from bdf07c2e16
(From OE-Core rev: f60637b3c9045656047d6ffcfaadbef5ad1d3d06)
Signed-off-by: Shubham Kulkarni <skulkarni@mvista.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Backport from go-1.19. The godebug package is needed by
the fix to CVE-2022-41725.
Mostly a cherry-pick but exceptions are noted in comments
marked "backport".
(From OE-Core rev: e5cf04f55b4849ae6db1253b39ad8b037cf01af4)
Signed-off-by: Joe Slater <joe.slater@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Disable cmd/internal/moddeps test, since this update includes PRIVATE
track fixes.
Backport from 5c3e11bd0b
(From OE-Core rev: 7440ebac50813e5df73da2d660a50fa97de650de)
Signed-off-by: Shubham Kulkarni <skulkarni@mvista.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Backport appropriate patches to fix CVE-2022-2879 and CVE-2022-41720.
Modified the original fix for CVE-2022-2879 to remove a testdata tarball
and any references to it since git binary diffs are not supported in
quilt.
(From OE-Core rev: a896cebe1ce2363b501723475154350acf0e0783)
Signed-off-by: Sakib Sajal <sakib.sajal@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
By default GOCACHE is set to $HOME/.cache.
Same issue for all other go recipes had been fixed by commit 9a6d208b:
[ go: avoid host contamination by GOCACHE ]
but that commit missed go-crosssdk recipe.
(From OE-Core rev: 803b754c64c8ee923cc02c17cf80798c93e3811c)
Signed-off-by: Robert Andersson <robert.m.andersson@atlascopco.com>
Signed-off-by: Ming Liu <liu.ming50@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
(cherry picked from commit e5fd10c647ac4baad65f9efa964c3380aad7dd10)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Update to latest v1.17.x release.
Contains fix for CVE-2022-32189.
go.git$ git log --oneline go1.17.12^..go1.17.13
15da892a49 (tag: go1.17.13, origin/release-branch.go1.17) [release-branch.go1.17] go1.17.13
703c8ab7e5 [release-branch.go1.17] math/big: check buffer lengths in GobDecode
d9242f7a8c [release-branch.go1.17] cmd/compile: do not use special literal assignment if LHS is address-taken
489c148578 [release-branch.go1.17] cmd/compile: fix prove pass when upper condition is <= maxint
66c60f076c [release-branch.go1.17] runtime: clear timerModifiedEarliest when last timer is deleted
c25b12fb81 [release-branch.go1.17] runtime: use saved LR when unwinding through morestack
1ed3c127da (tag: go1.17.12) [release-branch.go1.17] go1.17.12
(From OE-Core rev: 5acea6ee55d36987609bfa38b579ba86ca1879d1)
Signed-off-by: Sakib Sajal <sakib.sajal@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
go1.17.9 (released 2022-04-12) includes security fixes to the crypto/elliptic and
encoding/pem packages, as well as bug fixes to the linker and runtime.
go1.17.10 (released 2022-05-10) includes security fixes to the syscall package,
as well as bug fixes to the compiler, runtime, and the crypto/x509 and
net/http/httptest packages.
(From OE-Core rev: bcbfff47e212627b355c54ab782f38708ed12d4c)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is no reason to include a path in foo[dirs] if it is also in
foo[cleandirs] (except if it is the last path in foo[dirs]).
(From OE-Core rev: 9f610748f760b2d58d5250b55ae4b268909f33ef)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
