Go vulnerability check integration

[vivekpatani]

What happened?

Here's the go blog introduction post about Go Vulnerability Management tool - https://go.dev/blog/vuln

Is this something etcd should integrate?

What did you expect to happen?

N/A

How can we reproduce it (as minimally and precisely as possible)?

N/A

Anything else we need to know?

No response

Etcd version (please run commands below)

$ etcd --version
# paste output here

$ etcdctl version
# paste output here

Etcd configuration (command line flags or environment variables)

paste your configuration here

Etcd debug information (please run commands blow, feel free to obfuscate the IP address or FQDN in the output)

$ etcdctl member list -w table
# paste output here

$ etcdctl --endpoints=<member list> endpoint status -w table
# paste output here

Relevant log output

No response

[ahrtr]

Thanks @vivekpatani

It seems that the govulncheck requires golang version >= 1.18.

The scan result looks good! cc @spzala @ptabor

$ govulncheck ./...
govulncheck is an experimental tool. Share feedback at https://go.dev/s/govulncheck-feedback.

Scanning for dependencies with known vulnerabilities...
Found 2 known vulnerabilities.

Vulnerability #1: GO-2022-0288
  An attacker can cause unbounded memory growth in servers
  accepting HTTP/2 requests.

  Call stacks in your code:
      tools/etcd-dump-metrics/main.go:155:31: go.etcd.io/etcd/v3/tools/etcd-dump-metrics.main$4 calls go.etcd.io/etcd/server/v3/embed.StartEtcd, which eventually calls golang.org/x/net/http2.ConfigureServer$1

  Found in: golang.org/x/net/http2@v0.0.0-20211112202133-69e39bad7dc2
  Fixed in: golang.org/x/net/http2@v1.17.5
  More info: https://pkg.go.dev/vuln/GO-2022-0288

Vulnerability #2: GO-2022-0969
  HTTP/2 server connections can hang forever waiting for a clean
  shutdown that was preempted by a fatal error. This condition can
  be exploited by a malicious client to cause a denial of service.

  Call stacks in your code:
      tools/etcd-dump-metrics/main.go:155:31: go.etcd.io/etcd/v3/tools/etcd-dump-metrics.main$4 calls go.etcd.io/etcd/server/v3/embed.StartEtcd, which eventually calls golang.org/x/net/http2.ConfigureServer$1

  Found in: golang.org/x/net/http2@v0.0.0-20211112202133-69e39bad7dc2
  Fixed in: golang.org/x/net/http2@v1.19.1
  More info: https://pkg.go.dev/vuln/GO-2022-0969

Vulnerability #3: GO-2022-0969
  HTTP/2 server connections can hang forever waiting for a clean
  shutdown that was preempted by a fatal error. This condition can
  be exploited by a malicious client to cause a denial of service.

  Call stacks in your code:
      contrib/lock/storage/storage.go:100:21: go.etcd.io/etcd/v3/contrib/lock/storage.main calls net/http.ListenAndServe
      contrib/raftexample/httpapi.go:114:31: go.etcd.io/etcd/v3/contrib/raftexample.serveHttpKVAPI$1 calls net/http.Server.ListenAndServe
      tools/etcd-dump-metrics/main.go:155:31: go.etcd.io/etcd/v3/tools/etcd-dump-metrics.main$4 calls go.etcd.io/etcd/server/v3/embed.StartEtcd, which eventually calls net/http.Serve
      tools/etcd-dump-metrics/main.go:155:31: go.etcd.io/etcd/v3/tools/etcd-dump-metrics.main$4 calls go.etcd.io/etcd/server/v3/embed.StartEtcd, which eventually calls net/http.Server.Serve

  Found in: net/http@go1.18.6
  Fixed in: net/http@go1.19.1
  More info: https://pkg.go.dev/vuln/GO-2022-0969

=== Informational ===

The vulnerabilities below are in packages that you import, but your code
doesn't appear to call any vulnerable functions. You may not need to take any
action. See https://pkg.go.dev/golang.org/x/vuln/cmd/govulncheck
for details.

Vulnerability #1: GO-2022-0988
  JoinPath and URL.JoinPath do not remove ../ path elements appended
  to a relative path. For example, JoinPath("https://go.dev", "../go")
  returns the URL "https://go.dev/../go", despite the JoinPath documentation
  stating that ../ path elements are removed from the result.

  Found in: net/url@go1.18.6
  Fixed in: net/url@go1.19.1
  More info: https://pkg.go.dev/vuln/GO-2022-0988

Vulnerability #2: GO-2022-0493
  When called with a non-zero flags parameter, the Faccessat function
  can incorrectly report that a file is accessible.

  Found in: golang.org/x/sys/unix@v0.0.0-20210615035016-665e8c7367d1
  Fixed in: golang.org/x/sys/unix@v1.18.2
  More info: https://pkg.go.dev/vuln/GO-2022-0493

[ahrtr]

Above is the result against release-3.5, and below result is for main branch.

$ govulncheck ./...
govulncheck is an experimental tool. Share feedback at https://go.dev/s/govulncheck-feedback.

Scanning for dependencies with known vulnerabilities...
Found 1 known vulnerability.

Vulnerability #1: GO-2022-0969
  HTTP/2 server connections can hang forever waiting for a clean
  shutdown that was preempted by a fatal error. This condition can
  be exploited by a malicious client to cause a denial of service.

  Call stacks in your code:
      tools/etcd-dump-metrics/main.go:159:31: go.etcd.io/etcd/v3/tools/etcd-dump-metrics.main$4 calls go.etcd.io/etcd/server/v3/embed.StartEtcd, which eventually calls golang.org/x/net/http2.ConfigureServer$1

  Found in: golang.org/x/net/http2@v0.0.0-20220615171555-694bf12d69de
  Fixed in: golang.org/x/net/http2@v1.19.1
  More info: https://pkg.go.dev/vuln/GO-2022-0969

Vulnerability #2: GO-2022-0969
  HTTP/2 server connections can hang forever waiting for a clean
  shutdown that was preempted by a fatal error. This condition can
  be exploited by a malicious client to cause a denial of service.

  Call stacks in your code:
      contrib/lock/storage/storage.go:106:28: go.etcd.io/etcd/v3/contrib/lock/storage.main calls net/http.ListenAndServe
      contrib/raftexample/httpapi.go:113:31: go.etcd.io/etcd/v3/contrib/raftexample.serveHTTPKVAPI$1 calls net/http.Server.ListenAndServe
      tools/etcd-dump-metrics/main.go:159:31: go.etcd.io/etcd/v3/tools/etcd-dump-metrics.main$4 calls go.etcd.io/etcd/server/v3/embed.StartEtcd, which eventually calls net/http.Serve
      tools/etcd-dump-metrics/main.go:159:31: go.etcd.io/etcd/v3/tools/etcd-dump-metrics.main$4 calls go.etcd.io/etcd/server/v3/embed.StartEtcd, which eventually calls net/http.Server.Serve

  Found in: net/http@go1.18.6
  Fixed in: net/http@go1.19.1
  More info: https://pkg.go.dev/vuln/GO-2022-0969

=== Informational ===

The vulnerabilities below are in packages that you import, but your code
doesn't appear to call any vulnerable functions. You may not need to take any
action. See https://pkg.go.dev/golang.org/x/vuln/cmd/govulncheck
for details.

Vulnerability #1: GO-2022-0988
  JoinPath and URL.JoinPath do not remove ../ path elements appended
  to a relative path. For example, JoinPath("https://go.dev", "../go")
  returns the URL "https://go.dev/../go", despite the JoinPath documentation
  stating that ../ path elements are removed from the result.

  Found in: net/url@go1.18.6
  Fixed in: net/url@go1.19.1
  More info: https://pkg.go.dev/vuln/GO-2022-0988

[vivekpatani]

@ahrtr @ptabor @serathius so is the goal:

1. To make this part of the build pipeline?
2. If step 1 is implemented, we should fail to see if any are affected depending on severity?
3. Should this be backported to 3.4/3.5 too?

Thanks for the output @ahrtr, gives us a decent picture.

[ahrtr]

@vivekpatani Just as I mentioned above, pasted here again It seems that the govulncheck requires golang version >= 1.18.. So points:

1. It's a good idea to make the vulnerability check as part of the pipeline, but we can't do it until we upgrade the go version to 1.18 at least.
2. This definitely can't be backported to 3.5/3.4 due to the golang version mentioned above.

[vivekpatani]

@ahrtr yep, so should we spend time upgrading main to 1.18? The compatibility will be difficult to do so for 3.5.

[ahrtr]

Actually I am thinking probably we should upgrade to golang 1.19 directly on the main branch. Kubernetes already upgraded to 1.19.

What do you think? @serathius @spzala @ptabor

[ahrtr]

The golang has already been bumped to 1.19 in main branch.

@vivekpatani or anyone else, please feel free to investigate how to improve the pipeline to support the vulnerability scan.

[vivekpatani]

@ahrtr I have some bw now, will look at this. Thanks for upgrading to 1.19. First time doing GH actions, might take a bit longer than expected.

[ahrtr]

@vivekpatani Thanks. It isn't an urgent task, so no worries.

[ahrtr]

The ticket has already been resolved.