x/vuln/cmd/govulncheck: report stdlib CVEs

[qmuntal]

The Go Vulnerability Database has a bunch of CVEs associated to the standard library which are not reported by govulncheck.
Additionally, I would like to have my own database containing std packages and symbols sanctioned from secure applications, such as crypto/rc4.

My proposal is to add a new optional command line flag to govulncheck which specifies the Go version that should be vetted, i.e. -go=1.17.3. When this flag is set, govulncheck will load all the standard library vulnerabilities and filter them out by the provided Go version. Any std vulnerability finding would be treated and reported as if it were a normal module vulnerability.

Example:

Given the following main.go:

package main

import "crypto/elliptic"

func main() {
	println(elliptic.P224().IsOnCurve(nil, nil))
}

Currently govulncheck does not report any vulnerability.
With this proposal, it would report one when selecting an old Go version:

govulncheck -go=1.13.0 .
Findings for vulnerability: GO-2021-0235 (CVE-2021-3114):

Trace:
crypto/elliptic.p224Contract (C:\Program Files\Go\src\crypto\elliptic\p224.go:67:14)
crypto/elliptic.Curve.IsOnCurve(...) [approx. resolved to (crypto/elliptic.p224Curve).IsOnCurve] (C:\Users\*\code\gotest\main.go:6:35)
gotest.main(...) (C:\Users\*\code\gotest\main.go:5:6)

I leave out of this proposal to decide if the std check should be executed by default or not. AFAIU govulncheck would require the complete Go semantic version, which is not provided by go.mod, and this additional check would make govulncheck run slower.

cc @jba

[jba]

@zpavlinovic

[rittneje]

If you are analyzing an already compiled binary, I would expect it to look at runtime.buildVersion. And if you are analyzing source code, I would expect it to run go version. An explicit command line flag is probably only needed for more exotic cases.

[zpavlinovic]

Thanks for the suggestions! We have on our agenda to add support for Go standard library vulnerabilities. We don't have an exact timeline when the support will land, but we have been actively working on it.

Regarding your own database, there is already functionality for that. You can pass path to your db using GOVULNDB environment variable

The environment variable GOVULNDB can be set to a comma-separate list of vulnerability
database URLs, with http://, https://, or file:// protocols. Entries from multiple
databases are merged

This is a good place to start building you own db.

[qmuntal]

If you are analyzing an already compiled binary, I would expect it to look at runtime.buildVersion. And if you are analyzing source code, I would expect it to run go version. An explicit command line flag is probably only needed for more exotic cases.

Good points, if getting a good default Go version is as easy as using runtime.buildVersion or go version, then it is OK for me to report stdlib vulnerabilities by default.

I would still keep the command line flag regardless of the default behavior. My exotic case is the ability to spot vulnerabilities when the development Go version is not the same as the runtime Go version, without having to install multiple Go toolchains nor having to submit the code to a CI system.

Thanks for the suggestions! We have on our agenda to add support for Go standard library vulnerabilities. We don't have an exact timeline when the support will land, but we have been actively working on it.

I've seen that vulndb already supports stdlib vulnerabilities, which is great. Creating my own database is also really easy. In fact I created this proposal because the only piece that I think is missing is teaching govulncheck to support stdlib vulnerabilities.

I can work on this change if you are willing to accept contributions.

[zpavlinovic]

We are currently working on the new version (of UI for) govulncheck that should be up and running in the near future. We will definitely welcome community contributions then. I hope this works for you.

[qmuntal]

We are currently working on the new version (of UI for) govulncheck that should be up and running in the near future. We will definitely welcome community contributions then. I hope this works for you.

Sure, I'll wait until then!

[zpavlinovic]

Note: the new version of govulncheck is now in x/vuln/cmd/govulncheck. The previous version is not supported anymore and has been deleted.

[zpavlinovic]

govulncheck now supports detection of vulnerabilities in the Go standard library. The Go version checked against is the currently running one. Please see vulncheck API for more flexibility on input Go versions.

Please see vulndb on how to structure proprietary vulnerability databases, especially stdlib parts. For instance, one can run cmd/gendb command to generate local db and observe its layout.

[hyangah]

That is awesome.

One minor comment: what do you think about adjusting the text "Fixed in: ..." a bit for stdlib packages to use go version string style?

Currently reporting like the following:

Found in:  crypto/elliptic
Fixed in:  crypto/elliptic@v1.16.14

Instead, something like:

Found in: crypto/elliptic go1.16
Fixed in: crypto/eliptic go1.16.14

[julieqiu]

Thanks for catching @hyangah! I filed a separate issue for this: #53948