Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[20.10 backport] update to go1.19.6 #44990

Merged
merged 9 commits into from Mar 28, 2023

Conversation

thaJeztah
Copy link
Member

@thaJeztah thaJeztah commented Feb 13, 2023

Go announced a security update for Tomorrow, and while we don't know yet what this security fix includes (and whether or not it affects our code), the 1.18 release used for the 20.10 branch has reached EOL, so no releases will be done for that version.

This patch backports the Go updates to 1.19.6, so that we can have a run of CI with go1.19 in case a release is needed with an updated version of Go.

This patch backports (partially in some cases due to the switch to GHA on master);

@thaJeztah thaJeztah added this to the 20.10.24 milestone Feb 13, 2023
@thaJeztah thaJeztah mentioned this pull request Feb 15, 2023
5 tasks
@corhere corhere changed the title [20.10 backport] update to go1.19.5 [20.10 backport] update to go1.19.6 Feb 24, 2023
@corhere corhere force-pushed the 20.10_backport_update_go1.19 branch 2 times, most recently from 938ebeb to 694012e Compare February 24, 2023 22:12
thaJeztah and others added 9 commits February 27, 2023 11:28
also ran gofmt with go1.19

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 58413c1)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
From the mailing list:

We have just released Go versions 1.19.1 and 1.18.6, minor point releases.
These minor releases include 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.

Release notes:

go1.19.1 (released 2022-09-06) includes security fixes to the net/http and
net/url packages, as well as bug fixes to the compiler, the go command, the pprof
command, the linker, the runtime, and the crypto/tls and crypto/x509 packages.
See the Go 1.19.1 milestone on the issue tracker for details.

https://github.com/golang/go/issues?q=milestone%3AGo1.19.1+label%3ACherryPickApproved

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 1eadbdd)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
…-41715

From the mailing list:

We have just released Go versions 1.19.2 and 1.18.7, minor point releases.

These minor releases include 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.

View the release notes for more information: https://go.dev/doc/devel/release#go1.19.2

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 7b4e4c0)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Signed-off-by: Cory Snider <csnider@mirantis.com>
    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.

This Go release also fixes golang/go#56309, a
runtime bug which can cause random memory corruption when a goroutine
exits with runtime.LockOSThread() set. This fix is necessary to unblock
work to replace certain uses of pkg/reexec with unshared OS threads.

Signed-off-by: Cory Snider <csnider@mirantis.com>
(cherry picked from commit f9d4589)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Includes security fixes for net/http (CVE-2022-41717, CVE-2022-41720),
and os (CVE-2022-41720).

These minor releases include 2 security fixes following the security policy:

- 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 vX.Y.Z, 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.

View the release notes for more information:
https://go.dev/doc/devel/release#go1.19.4

And the milestone on the issue tracker:
https://github.com/golang/go/issues?q=milestone%3AGo1.19.4+label%3ACherryPickApproved

Full diff: golang/go@go1.19.3...go1.19.4

The golang.org/x/net fix is in golang/net@1e63c2f

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 52bc1ad)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
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 the issue tracker for details:

https://github.com/golang/go/issues?q=milestone%3AGo1.19.5+label%3ACherryPickApproved

full diff: golang/go@go1.19.4...go1.19.5

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 155e8d7)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
go1.19.6 (released 2023-02-14) includes security fixes to the crypto/tls,
mime/multipart, net/http, and path/filepath packages, as well as bug fixes to
the go command, the linker, the runtime, and the crypto/x509, net/http, and
time packages. See the Go 1.19.6 milestone on our issue tracker for details:

https://github.com/golang/go/issues?q=milestone%3AGo1.19.6+label%3ACherryPickApproved

From the announcement on the security mailing:

We have just released Go versions 1.20.1 and 1.19.6, minor point releases.

These minor releases include 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.

  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
  ntry 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.

  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).

  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.

  This is CVE-2022-41723 and Go issue https://go.dev/issue/57855.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 94feb31)
Signed-off-by: Cory Snider <csnider@mirantis.com>
@corhere corhere marked this pull request as ready for review February 27, 2023 16:29
@neersighted neersighted merged commit ba043e8 into moby:20.10 Mar 28, 2023
@thaJeztah
Copy link
Member Author

Oh! We should probably also take the 1.19.7 update (forgot to update this one)

@thaJeztah thaJeztah deleted the 20.10_backport_update_go1.19 branch March 28, 2023 17:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants