Report Go runtime vulnerabilities based on the runtime detected in a Go binary

[dbrugman]

What happened:
While scanning a Docker image that contains a binary that was compiled with the Go compiler and statically linked against the Go runtime library version 1.19.9, this binary was correctly found and identified by the go-module-binary-cataloger. However, it was not flagged as impacted by CVE-2023-29403, which impacts the Go runtime library for versions < 1.19.10. Note that this binary was compiled with debug symbols (not stripped)

What you expected to happen:
I would have expected this binary to be flagged as impacted by CVE-2023-29403, since it was statically linked against a vulnerable runtime library.

How to reproduce it (as minimally and precisely as possible):
Scan a Docker image that contains a Go binary with debug symbols that has been compiled with Go version 1.19.9 or below, and is statically linked against the Go runtime library.

Anything else we need to know?:

Environment:

• Output of grype version:
  Application: grype
  Version: 0.63.0
  Syft Version: v0.84.0
  BuildDate: 2023-06-21T16:11:07Z
  GitCommit: ca79c2a
  GitDescription: v0.63.0
  Platform: linux/amd64
  GoVersion: go1.19.10
  Compiler: gc
  Supported DB Schema: 5

• OS (e.g: cat /etc/os-release or similar):
  NAME="Ubuntu"
  VERSION="20.04.6 LTS (Focal Fossa)"
  ID=ubuntu
  ID_LIKE=debian
  PRETTY_NAME="Ubuntu 20.04.6 LTS"
  VERSION_ID="20.04"
  HOME_URL="https://www.ubuntu.com/"
  SUPPORT_URL="https://help.ubuntu.com/"
  BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
  PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
  VERSION_CODENAME=focal
  UBUNTU_CODENAME=focal

[tgerla]

Hi @dbrugman, thanks for the report. Do you happen to have a publicly available image or a relevant go binary that exhibits this behavior that we can use to reproduce? We'll take a look. Thanks!

[dbrugman]

Thanks for looking into this @tgerla! I detected this on a proprietary image, but after a little searching I found a public image where this can be reproduced: quay.io/calico/kube-controllers:v3.20.0.

That image has a Go-compiled binary: /usr/bin/kube-controllers. This binary is compiled with Go version 1.15.2, so the Go runtime library should be vulnerable to CVE-2023-29403. This binary does get detected by Grype, and it reports several vulnerabilities for this binary, but not the CVE in question.

Note that CVE-2023-29403 was released with a few other related CVE's: CVE-2023-29402, CVE-2023-29404 and CVE-2023-29405. The other three CVE's affect the Go compiler itself, but CVE-2023-29403 affects the runtime library. When I look in the Grype vulnerability DB, it seems like all four of these CVE's have been defined as impacting the Go compiler. I think that's the reason it doesn't get detected. Also: the component list generated by Grype for kube-controllers lists a dozen or so Go libraries, but there is no entry for the OOTB 'runtime' library. Without such an entry it might be hard to define a 'target' for the vulnerability.

[willmurphyscode]

Thanks for the repro steps! I wanted to add some additional context to this issue:

Root cause: The reason Grype isn't finding this is because, although syft reports the go compiler version of each go binary in the package metadata, syft does not report the go runtime library as its own package, so vulnerabilities against the go runtime library are not reported.

We could update the go binary cataloger in syft to report the runtime library as its own package, as we do with other dependencies built into the go binary. There are a couple of considerations here:

1. As you mentioned above, some vulnerabilities reported against Go itself are compile time vulnerabilities, and shouldn't be reported here. This might be solved by Add support for package dependency relationships syft#572, which would let syft write down the distinction between runtime and compile time dependencies, for example.
2. Syft currently deduplicates the SBOM artifacts by path, so every go binary would report its version of the go runtime library at the path where the library was, so an image with lots of go binaries built with the same go version would have a lot of noise in the SBOM. This might be solved by adding custom deduplication logic to the go cataloger itself.

That said, I do think this behavior (missing a CVE reported against the go runtime lib) is good evidence we should make this change in syft.

[dbrugman]

@willmurphyscode thanks for the detailed analysis! I think your suggestions make sense, even though my understanding of Syft internals is limited. I’ll start following syft#572 as well.

[westonsteimel]

@tgerla - I believe this has been addressed awhile ago by the syft changes in anchore/syft#2195

[kzantow]

Good catch! I just retested this on the latest grype and it works as expected:

$ grype quay.io/calico/kube-controllers:v3.20.0 -q | grep 29403
stdlib               go1.15.2              go-module  CVE-2023-29403       High      

I'm going to close this, since it has been implemented but please reopen if there's a misunderstanding!