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

Detect the version of the Go binary itself #1837

Closed
phoenixadb opened this issue Mar 16, 2022 · 12 comments · Fixed by #6530
Closed

Detect the version of the Go binary itself #1837

phoenixadb opened this issue Mar 16, 2022 · 12 comments · Fixed by #6530
Assignees
Labels
kind/feature Categorizes issue or PR as related to a new feature. lifecycle/stale Denotes an issue or PR has remained open with no activity and will be auto-closed.

Comments

@phoenixadb
Copy link

Description

Hello, we found a strange behaviour with Trivy while analyzing the Docker image minio/minio:RELEASE.2021-09-03T03-56-13Z.

The vulnerability CVE-2021-43858 doesn't show in the report.

What did you expect to happen?

To have this vulnerability inside the report.

What happened instead?

The vulnerability is not in the report.

@phoenixadb phoenixadb added the kind/bug Categorizes issue or PR as related to a bug. label Mar 16, 2022
@knqyf263
Copy link
Collaborator

@DmitriyLewen Would you take a look?

@DmitriyLewen
Copy link
Contributor

Hello @phoenixadb
Thanks for your report!
I will try to reproduce your problem and write to you later.

Regards, Dmitriy

@DmitriyLewen
Copy link
Contributor

Hello @phoenixadb
Thanks for waiting!
minio/minio:RELEASE.2021-09-03T03-56-13Z includes usr/bin/minio binary file. This binary has vulnerability CVE-2021-43858.
Trivy can parse the library dependencies and version of a Golang binary but not the binary version.
That is why Trivy doesn't detect CVE-2021-43858 vulnerability.
We already have such problems (#1459 , #1377), but now we have no way to get the binary version.

Regards, Dmitriy

@phoenixadb
Copy link
Author

phoenixadb commented Mar 23, 2022

Hi @DmitriyLewen,

Thank you for your answer.

Even when compiled readelf displays no version number. When using the compiled binary (./minio --version), it displays "minio version DEVELOPMENT.GOGET".

The only way will be to compare URL from downloaded release with CPE from MITRE to check vulnerabilities.
curl -s -q https://dl.min.io/server/minio/release/linux-${TARGETARCH}/archive/minio.${RELEASE}

@DmitriyLewen
Copy link
Contributor

Hello @phoenixadb
This way will only work for mini.
But we need a generic method for any goBinary files.

@knqyf263 knqyf263 added kind/feature Categorizes issue or PR as related to a new feature. and removed kind/bug Categorizes issue or PR as related to a bug. labels Apr 6, 2022
@knqyf263 knqyf263 changed the title CVE-2021-43858 not recognized Detect the version of the Go binary itself Apr 6, 2022
@github-actions
Copy link

This issue is stale because it has been labeled with inactivity.

@github-actions github-actions bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and will be auto-closed. label Jun 18, 2022
@zythosec
Copy link

@DmitriyLewen Go provides this functionality via the go binary using the version command

  • go version <binary_name> prints the go version with which it was built
  • go version -m <binary_name> also includes the dependencies

Would that functionality be able to be leveraged?

@knqyf263
Copy link
Collaborator

We already use go version -m, but it doesn't contain the application version, but dependency versions.

$ go version -m ./trivy
./trivy: go1.18.3
        path    command-line-arguments
        dep     cloud.google.com/go     v0.99.0 h1:y/cM2iqGgGi5D5DQZl6D9STN/3dR/Vx5Mp8s752oJTY=
        dep     cloud.google.com/go/storage     v1.14.0 h1:6RRlFMv1omScs6iq2hfE3IvgE+l6RfJPampq8UZc5TU=
        dep     github.com/Azure/azure-sdk-for-go       v65.0.0+incompatible    h1:HzKLt3kIwMm4KeJYTdx9EbjRYTySD/t8i1Ee/W5EGXw=
        dep     github.com/Azure/go-autorest/autorest   v0.11.27        h1:F3R3q42aWytozkV8ihzcgMO4OA4cuqr3bNlsEuF6//A=

We cannot know which version trivy is.

@zythosec
Copy link

Oh got it. My confusion. 😅 I thought this pertained to the Go version.

@github-actions github-actions bot removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and will be auto-closed. label Jun 28, 2022
@github-actions
Copy link

This issue is stale because it has been labeled with inactivity.

@github-actions github-actions bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and will be auto-closed. label Aug 27, 2022
@ericrrath
Copy link

Not sure if it's poor form to comment on a closed issue, but this seems like the most relevant place. If you use go install ..., the binary that ends up in your go/bin dir will have a line in the go version -m ... output indicating the name and version of the "main module", e.g.:

$ go version -m ~/go/bin/helm
...
	path	helm.sh/helm/v3/cmd/helm
	mod	helm.sh/helm/v3	v3.13.2	h1:IcO9NgmmpetJODLZhR3f3q+6zzyXVKlRizKFwbi7K8w=
	dep	github.com/BurntSushi/toml	v1.3.2	h1:o7IhLm0Msx3BaB+n3Ag7L8EVlByGnpq14C4YWiu/gL8=
...

shows helm.sh/helm/v3 v3.13.2 and

$ go version -m ~/go/bin/staticcheck
...
	path	honnef.co/go/tools/cmd/staticcheck
	mod	honnef.co/go/tools	v0.4.6	h1:oFEHCKeID7to/3autwsWfnuv69j3NsfcXbvJKuIcep8=
	dep	github.com/BurntSushi/toml	v1.2.1	h1:9F2/+DoOYIOksmaJFPw1tGFy1eDnIJXg+UHjuD8lTak=
...

shows honnef.co/go/tools v0.4.6. So there seems to be a "canonical" way to stamp the name and version of the binary itself, but it appears to only happen when go install is used with a recognized version.

FWIW, there's discussion in this golang issue about stamping binaries when using go build (instead of only when using go install), but there's no clear resolution yet.

@knqyf263
Copy link
Collaborator

@ericrrath Thanks for sharing! We were not aware of that. It's really interesting. Then, we can add support for binaries with go install.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature. lifecycle/stale Denotes an issue or PR has remained open with no activity and will be auto-closed.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants