Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

x/vuln/cmd/govulncheck: report stdlib CVEs #51653

Closed
qmuntal opened this issue Mar 14, 2022 · 10 comments
Closed

x/vuln/cmd/govulncheck: report stdlib CVEs #51653

qmuntal opened this issue Mar 14, 2022 · 10 comments
Assignees
@zpavlinovic
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. vulncheck or vulndb Issues for the x/vuln or x/vulndb repo
Milestone
vuln/2022

Comments

@qmuntal
Copy link
Contributor

qmuntal commented Mar 14, 2022 •
edited

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
@gopherbot gopherbot added this to the Proposal milestone Mar 14, 2022
@jba
Copy link
Contributor

jba commented Mar 14, 2022

@zpavlinovic

@rittneje
Copy link

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
Copy link
Contributor

zpavlinovic commented Mar 15, 2022 •
edited

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
Copy link
Contributor Author

qmuntal commented Mar 15, 2022

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
Copy link
Contributor

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
Copy link
Contributor Author

qmuntal commented Mar 16, 2022

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!

@ianlancetaylor ianlancetaylor added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Mar 16, 2022
@ianlancetaylor ianlancetaylor modified the milestones: Proposal, Unreleased Mar 16, 2022
@ianlancetaylor ianlancetaylor changed the title proposal: x/exp/vulndb/govulncheck: report stdlib CVEs x/exp/vulndb/govulncheck: report stdlib CVEs Mar 16, 2022
@zpavlinovic zpavlinovic changed the title x/exp/vulndb/govulncheck: report stdlib CVEs x/vuln/cmd/govulncheck: report stdlib CVEs Mar 24, 2022
@zpavlinovic
Copy link
Contributor

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
Copy link
Contributor

zpavlinovic commented Jul 13, 2022 •
edited

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
Copy link
Contributor

hyangah commented Jul 14, 2022

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 julieqiu mentioned this issue Jul 18, 2022
Closed
@julieqiu
Copy link
Member

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

@julieqiu julieqiu added the vulncheck or vulndb Issues for the x/vuln or x/vulndb repo label Sep 8, 2022
@julieqiu julieqiu modified the milestones: Unreleased, vuln/2022 Sep 8, 2022
@zpavlinovic zpavlinovic self-assigned this Sep 8, 2022
@golang golang locked and limited conversation to collaborators Sep 8, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@zpavlinovic zpavlinovic

Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. vulncheck or vulndb Issues for the x/vuln or x/vulndb repo
Projects
Go Security
Status: Done
Milestone
vuln/2022
Development

No branches or pull requests
8 participants
@zpavlinovic @ianlancetaylor @qmuntal @hyangah @julieqiu @gopherbot @jba @rittneje