crictl flagged for vulerabilities
yehiyam opened this issue · comments
What happened:
crictl executable is flagged for vulnerabilities in Go packages:
- golang.org/x/net v0.14.0. upgrade to 0.17.0. I saw that it is fixed but not released yet
- go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp v0.35.1. upgrade to 0.44.0
What you expected to happen:
What is the schedule for the next release?
I would also like to know when the next release will be!
Usually the next version would be released with Kubernetes v1.29 in December. While the packages are vulnerable, are we sure that we're affected by those vulnerabilities?
@saschagrunert I do not know if we are affected.
I don't think we are. Can you confirm @kwilczynski?
@yehiyam @saschagrunert, the scanners would pick the following most likely:
- govulncheck:
Scanning your code and 737 packages across 88 dependent modules for known vulnerabilities...
=== Informational ===
Found 2 vulnerabilities in packages that you import, but there are no call
stacks leading to the use of these vulnerabilities. You may not need to
take any action. See https://pkg.go.dev/golang.org/x/vuln/cmd/govulncheck
for details.
Vulnerability #1: GO-2023-2113
Memory exhaustion in github.com/open-telemetry/opentelemetry-go-contrib
More info: https://pkg.go.dev/vuln/GO-2023-2113
Module: go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp
Found in: go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp@v0.35.1
Fixed in: go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp@v0.44.0
Vulnerability #2: GO-2023-2048
Paths outside of the rootfs could be produced on Windows
More info: https://pkg.go.dev/vuln/GO-2023-2048
Module: github.com/cyphar/filepath-securejoin
Found in: github.com/cyphar/filepath-securejoin@v0.2.3
Fixed in: github.com/cyphar/filepath-securejoin@v0.2.4
Platforms: windows
No vulnerabilities found.
Share feedback at https://go.dev/s/govulncheck-feedback.
- osv-scanner:
╭─────────────────────────────────────┬──────┬───────────┬───────────────────────────────────────────────────────────────┬─────────┬────────╮
│ OSV URL │ CVSS │ ECOSYSTEM │ PACKAGE │ VERSION │ SOURCE │
├─────────────────────────────────────┼──────┼───────────┼───────────────────────────────────────────────────────────────┼─────────┼────────┤
│ https://osv.dev/GHSA-6xv5-86q9-7xr8 │ │ Go │ github.com/cyphar/filepath-securejoin │ 0.2.3 │ go.mod │
│ https://osv.dev/GO-2023-2048 │ │ │ │ │ │
│ https://osv.dev/GHSA-rcjv-mgp8-qvmr │ 7.5 │ Go │ go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp │ 0.35.1 │ go.mod │
│ https://osv.dev/GO-2023-2113 │ │ │ │ │ │
│ https://osv.dev/GHSA-m425-mq94-257g │ 7.5 │ Go │ google.golang.org/grpc │ 1.54.0 │ go.mod │
│ https://osv.dev/GHSA-qppj-fm5r-hxr3 │ 5.3 │ Go │ google.golang.org/grpc │ 1.54.0 │ go.mod │
╰─────────────────────────────────────┴──────┴───────────┴───────────────────────────────────────────────────────────────┴─────────┴────────╯
Some of these reported vulnerabilities are against dependencies that aren't our direct dependencies. Some used to be direct but eventually moved as we upgraded other dependencies, for example:
From the above (an excerpt from the larger changeset):
@@ -18,8 +18,8 @@ require (
github.com/sirupsen/logrus v1.8.1
github.com/urfave/cli/v2 v2.4.0
golang.org/x/net v0.0.0-20211209124913-491a49abca63
- golang.org/x/sys v0.0.0-20211216021012-1d35b9e2eb4e
- google.golang.org/grpc v1.45.0
+ golang.org/x/sys v0.0.0-20220114195835-da31bd327af9
+ google.golang.org/grpc v1.45.0 // indirect
gopkg.in/yaml.v3 v3.0.0-20210107192922-496545a6307b
k8s.io/api v0.23.1
k8s.io/apimachinery v0.23.1Currently:
$ go mod why google.golang.org/grpc github.com/cyphar/filepath-securejoin go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp
# google.golang.org/grpc
github.com/kubernetes-sigs/cri-tools/cmd/crictl
k8s.io/cri-api/pkg/apis/runtime/v1
google.golang.org/grpc
# github.com/cyphar/filepath-securejoin
github.com/kubernetes-sigs/cri-tools/pkg/validate
github.com/opencontainers/runc/libcontainer/apparmor
github.com/opencontainers/runc/libcontainer/utils
github.com/cyphar/filepath-securejoin
# go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp
github.com/kubernetes-sigs/cri-tools/cmd/crictl
k8s.io/kubernetes/pkg/kubelet/cri/remote
k8s.io/component-base/tracing
go.opentelemetry.io/contrib/instrumentation/net/http/otelhttpWe are also not exposing any listeners of QUIC, HTTP/2, gRPC, etc., where most of the recent vulnerabilities were mainly exposed.
Yes, it would be nice to keep the dependencies up-to-date as soon as there are issues, but when nothing is affecting us directly within the immediate code base or some crucial dependency, then deferring upgrades is an option, too.
We will upgrade the Go version and the dependencies soon, just before another release, as @saschagrunert said.
@yehiyam, are you having issues with your security scanners? Some compliance problems? Because of our outdated dependencies?
@kwilczynski
We are having the binary flagged by our security scanner.
We got flagged for:
CVE-2023-39325, CVE-2023-44487 (golang.org/x/net)
CVE-2023-45142 (go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp)
GHSA-m425-mq94-257g (google.golang.org/grpc)
@kwilczynski We are having the binary flagged by our security scanner.
I thought you would. Sorry about that!
We got flagged for: CVE-2023-39325, CVE-2023-44487 (golang.org/x/net)
CVE-2023-45142 (go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp)
GHSA-m425-mq94-257g (google.golang.org/grpc)
None of these affect cri-tools at the moment. Even though it might look like it - this is mainly due to scanners seeing dependencies, which in our case are indirect and/or transitive, as we do not have any servers or listeners in a primarily command-line client utility.
You can put your security team at ease about the reports.
That said, I am not sure when there will be a new release of cri-tools - unless @saschagrunert deems that it might be prudent to make one in order to bring more up-to-date dependencies.
@kwilczynski / @saschagrunert : I vote +1 on @yehiyam to publish a new release just to bump up the dependencies
@tshaiman, with people back from KubeCon, I am sure that work on the new release will move forward. 😄
@tshaiman we're cutting Kubernetes v1.29.0 in 3 weeks, can we wait for that considering that the code actually not affected?
Sure @saschagrunert
@saschagrunert seems the 1.129 release didn't take care for CVE-2023-47108
can you share what is the plan to patch this one?
@Yoni-Mantzur we're not affected by this CVE, because:
In order to be affected, the program has to configure a metrics pipeline, use UnaryServerInterceptor, and does not filter any client IP address and ports via middleware or proxies, etc.
@saschagrunert, same here. This probably can be closed.
There is nothing for us to immediately do here. I suppose.