Open BenjaminPelletier opened 3 years ago
Please note that a new Dependency Check report is now available, generated by running dependency-check --enableExperimental --scan go.mod
from the repo root folder on commit 5f2f60afe73cacc2c3b6a5f142ed513857579c87 after installing dependency-check
via brew.
Dependency-Check Report Dependency-Check Report.pdf
In the above report, the dependencies github.com/grpc-ecosystem/go-grpc-middleware:1.2.2
and github.com/grpc-ecosystem/grpc-gateway:1.16.0
are flagged with the vulnerability IDs cpe:2.3:a:grpc:grpc:1.2.2:*:*:*:*:*:*:*
and cpe:2.3:a:grpc:grpc:1.16.0:*:*:*:*:*:*:*
respectively. For go-grpc-middleware
, the published vulnerabilities listed are CVE-2017-9431
and CVE-2020-7768
. For grpc-gateway
, only CVE-2020-7768 is listed.
CVE-2017-8359
The original dependency check report run prior to commit 5f2f60a indicates the vulnerability CVE-2017-8359
. This CVE specifies that the problem affects gRPC up to and including v1.2.1. Dependency Check seems to be searching for gRPC 1.2.0 in the CPE search string, but this is not valid because go-grpc-middleware
is not gRPC. Instead, v1.2.0 of go-grpc-middleware
uses v1.19.0 of gRPC, which is far past the relevant v1.2.0 version. This logic can be verified by observing that CVE-2017-8359
no longer appears in the list of vulnerabilities of the second dependency check after the go-grpc-middleware
version was updated to v1.2.2. The version of gRPC that v1.2.2 of go-grpc-middleware
references is v1.29.1. So, I believe Dependency Check incorrectly confused go-grpc-middleware
with the core grpc
package and CVE-2017-8359
was never applicable to this project.
CVE-2017-9431
This vulnerability applies to gRPC up to, and including, v1.2.2. Like CVE-2017-8359
above, this repo has never referenced v1.2.2 (or earlier) of the core gRPC code, the fix for which was applied in 2017 and is contained in v1.19.0 of gRPC (git tag --contains 55a61e43b9abe9c95a6e401239bdd02a48deb587
in grpc
repo) which is what is referenced by go-grpc-middleware:1.14.3
. I believe Dependency Check is incorrectly confusing go-grpc-middleware
with the core grpc
package and CVE-2017-9431
was never applicable to this project.
CVE-2020-7768
This vulnerability appears to be incorrectly derived from go-grpc-middleware
's and go-grpc-gateway
's versions being confused with the core grpc
package version like the previous two vulnerabilities. However, the affected core grpc
packages were up to (but excluding) v1.24.2, and go-grpc-middleware:1.2.0
referenced only grpc:1.19.0
so this vulnerability may have applied (via go-grpc-middleware
) prior to 5f2f60a. go-grpc-middleware
is now referenced at v1.2.2 which references grpc
at v1.29.1, so the vulnerability should no longer apply via go-grpc-middleware
. The grpc-gateway:1.14.3
reference prior to 5f2f60a referred to grpc:1.24.0
, so the vulnerability may have applied there as well. However, 5f2f60a revs to grpc-gateway:1.16.0
which refers to grpc:1.33.1
, so the vulnerability should no longer apply via grpc-gateway
. Further support of this evaluation comes from running Dependency Check on the two included libraries themselves: https://github.com/grpc-ecosystem/go-grpc-middleware and https://github.com/grpc-ecosystem/grpc-gateway. When go-grpc-middleware
is checked out to tag v1.2.0
, Dependency Check (probably correctly) detects this CVE due to its reference to grpc:1.19.0
. When go-grpc-middleware
is checked out to tag v1.2.2
, Dependency Check no longer detects this CVE. Likewise with grpc-gateway
at tags v1.14.3
and v1.16.0
.
Conclusion
The vulnerabilities listed for github.com/grpc-ecosystem/go-grpc-middleware:1.2.2
and github.com/grpc-ecosystem/grpc-gateway:1.16.0
in the most recent Dependency Check report are not relevant and do not affect the current version of the repository. Dependency Check incorrectly matched grpc
package versions to version of go-grpc-middleware
and grpc-gateway
packages.
The script in #480 produces the dependency graph below for all the vulnerabilities mentioned in the Dependency Check report except prometheus/*
:
All packages with listed vulnerabilities except robfig/cron
, prometheus/*
(not included on graph), go-grpc-middleware
, and grpc-gateway
are included via golang-migrate/migrate
. This package is used only by the database schema manager, which is only invoked from within the Kubernetes cluster when deployed in the standard manner. The schema manager is short-lived and is only invoked (manually, by a cluster admin) when the database schema changes. Due to these factors, I do not believe any of the vulnerabilities associated with golang-migrate/migrate
are practically exploitable in any version of this repo.
The graph above can be reproduced with python why_go_dep.py github.com/apache/thrift github.com/docker/distribution github.com/docker/docker github.com/docker/go-connections github.com/docker/go-units github.com/go-sql-driver/mysql github.com/grpc-ecosystem/go-grpc-middleware github.com/grpc-ecosystem/grpc-gateway github.com/robfig/cron github.com/xanzy/go-gitlab modernc.org/file
on a system with Python 3 and GraphViz installed from the root of this repo.
Like the comment above regarding Dependency Check's confusion of grpc
vulnerabilities with go-grpc-middleware
and grpc-gateway
, Dependency Check's identification of a vulnerability in robfig/cron
appears to be the same misidentification of a similarly-named tool with the core package it is related to. The mentioned CVEs (CVE-2017-9525
, CVE-2019-9704
, CVE-2019-9705
) all appear to refer to the cron
utility itself. robfig/cron
is not the cron
utility itself, but rather a Go package with no dependencies other than Go itself intended to interact with the cron
utility that is already installed on the user's system. For this reason, I believe the vulnerabilities associated with robfig/cron
in the Dependency Check report are not applicable to this project.
The last remaining dependency vulnerability in the second Dependency Check report that is not addressed in the comments above is the one relating to Prometheus. Only prometheus/client_model
is referenced by this repo as of 5f2f60a:
$ go mod graph | grep prometheus
github.com/envoyproxy/go-control-plane@v0.9.9-0.20201210154907-fd9021fe5dad github.com/prometheus/client_model@v0.0.0-20190812154241-14fe0d1b01d4
github.com/prometheus/client_model@v0.0.0-20190812154241-14fe0d1b01d4 github.com/golang/protobuf@v1.2.0
github.com/prometheus/client_model@v0.0.0-20190812154241-14fe0d1b01d4 golang.org/x/sync@v0.0.0-20181108010431-42b317875d0f
github.com/envoyproxy/go-control-plane@v0.9.1-0.20191026205805-5f8ba28d4473 github.com/prometheus/client_model@v0.0.0-20190812154241-14fe0d1b01d4
github.com/envoyproxy/go-control-plane@v0.9.4 github.com/prometheus/client_model@v0.0.0-20190812154241-14fe0d1b01d4
github.com/envoyproxy/go-control-plane@v0.9.0 github.com/prometheus/client_model@v0.0.0-20190812154241-14fe0d1b01d4
The prometheus/client_model
package is merely the means by which to communicate with a Prometheus instance via Protocol Buffers; it does not depend on a Prometheus implementation. CVE-2019-3826
refers to the Prometheus implementation at https://github.com/prometheus/prometheus, not the client_model
indirectly referenced by this repo. For this reason, I believe the vulnerability listed in Dependency Check for Prometheus with regard to Go dependencies is a false positive in the same way as for go-grpc-middleware
, grpc-gateway
, and robfig/cron
above; this vulnerability is not applicable to this repo.
The deployment in this repo does create a Prometheus instance, however, from the latest
tag of the Docker Hub image repository. As of this comment, the Prometheus version referenced by this tag was 2.25.0, which is unaffected by CVE-2019-3826 as that issue was resolved in 2.7.1.
Therefore, I believe the Prometheus vulnerability listed in the latest Dependency Check is not applicable to this repo.
Since it appears that Dependency Check does not reveal any exploitable vulnerabilities as of 5f2f60a, reducing the priority of this issue to a P2.
A dependency check as of Jan 12 2021 shows vulnerabilities in package dependencies (both direct and indirect). Most of these vulnerabilities are fixed in later versions, and can therefore be addressed by updating referenced package versions.
Dependency-Check Report.pdf