Dependency check shows vulnerabilities in dependent packages

[BenjaminPelletier]

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

[BenjaminPelletier]

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 5f2f60a after installing dependency-check via brew.

Dependency-Check Report
Dependency-Check Report.pdf

[BenjaminPelletier]

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.

[BenjaminPelletier]

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.

[BenjaminPelletier]

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.

[BenjaminPelletier]

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/[email protected] github.com/prometheus/[email protected]
github.com/prometheus/[email protected] github.com/golang/[email protected]
github.com/prometheus/[email protected] golang.org/x/[email protected]
github.com/envoyproxy/[email protected] github.com/prometheus/[email protected]
github.com/envoyproxy/[email protected] github.com/prometheus/[email protected]
github.com/envoyproxy/[email protected] github.com/prometheus/[email protected]

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.

[BenjaminPelletier]

Since it appears that Dependency Check does not reveal any exploitable vulnerabilities as of 5f2f60a, reducing the priority of this issue to a P2.