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

[release/2.8] vendor: golang.org/x/net v0.17.0 #4118

Merged
merged 1 commit into from Oct 19, 2023

Conversation

thaJeztah
Copy link
Member

@thaJeztah thaJeztah commented Oct 19, 2023

full diff: golang/net@4876518...b225e7c

This fixes the same CVE as go1.21.3 and go1.20.10;

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

@thaJeztah

This comment was marked as outdated.

@thaJeztah
Copy link
Member Author

Ah, fun; looks like golang.org/x/net/publicsuffix now uses go:embed, but the files it's embedding are pruned by vndr (as it considers them to be unrelated, and there's no go source-files in the directory); https://github.com/golang/net/tree/1e23797619c957fb2d0a7ed9ae1083fb31f592b8/publicsuffix/data

> [linux/amd64->arm/v6 build 1/1] RUN --mount=type=bind,target=/go/src/github.com/docker/distribution,rw     --mount=type=cache,target=/root/.cache/go-build     --mount=target=/go/pkg/mod,type=cache     --mount=type=bind,source=/tmp/.ldflags,target=/tmp/.ldflags,from=version       set -x ; xx-go build -tags "include_oss,include_gcs" -trimpath -ldflags "$(cat /tmp/.ldflags) -s -w" -o /usr/bin/registry ./cmd/registry       && xx-verify --static /usr/bin/registry:
0.349 + cat /tmp/.ldflags
0.362 + xx-go build -tags include_oss,include_gcs -trimpath -ldflags '-X github.com/docker/distribution/version.Version=2.8.3-6-g9a0b1948 -X github.com/docker/distribution/version.Revision=9a0b19483049cbf6fca55e09f1474f713260c1a5 -X github.com/docker/distribution/version.Package=github.com/docker/distribution -s -w' -o /usr/bin/registry ./cmd/registry
1.764 vendor/golang.org/x/net/publicsuffix/table.go:63:12: pattern data/children: no matching files found

full diff: golang/net@4876518...b225e7c

This fixes the same CVE as go1.21.3 and go1.20.10;

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

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Comment on lines +6 to +9
# Prevent the data directory from being pruned; this directory does not contain
# go source files (causing vndr to prune it), however these files are used by
# golang.org/x/net/publicsuffix through go:embed.
vndr -whitelist golang.org/x/net/publicsuffix/data |& grep -v -i clone
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like this works; add a -whitelist option to prevent vndr from pruning the files; we don't have a make vendor target, so when we update dependencies, we'll have to remember setting this option.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't wait for the moment we won't have to maintain this cruft. Sooooon.

@milosgajdos milosgajdos merged commit 3c82e8a into distribution:release/2.8 Oct 19, 2023
3 checks passed
@thaJeztah thaJeztah deleted the 2.8_update_x_net branch October 19, 2023 10:40
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