gosu vulnerabilities and usage of End-of-Life Version of GO

[jhawkins1]

In December there was an issue to move to newer version of gosu to address vulnerabilities, however, that move to newer gosu had minimal impact on CVE reduction.

gosu is being flagged by industry vulnerability scanners with GO vulnerabilities associated with the version of GO being used by gosu. (53 CVEs at the time of this issue) Also, security auditors flag gosu for using an EOL version of GO. Multiple issues have been logged to the gosu project over time by many dependent projects, or users of the software. The gosu maintainer refuses to update and his feedback is gosu itself is not vulnerable due to GO as gosu does not use the affected GO modules or execution paths, and he has no plans to update GO even though the version used is EOL. This leaves individuals or companies in a bad state due to vulnerability management requirements dictatating the clearance of CVEs in a timely fashion (whether potential False Positives or not) along with no usage of EOL software.

The Cassandra Docker Image is affected by the gosu issue. As to potential solutions, assuming the gosu maintainers continues the refusal position, would be Cassandra rebuild gosu with newer version of GO and include in the Image or replace gosu with alternate approach. Alternatively, the consumers of the Cassandra Image could create a derived Image and implement their alternatives on their own.

Thoughts on how to proceed? Is this something the project would address or adopt proposed PR fixes to this issue?

[yosifkit]

Basically every CVE scanner that I've seen uses inaccurate string matching and doesn't account for execution path. I.E., just because a binary uses a library, doesn't mean it uses the specific function in the library that has a defect.

Fortunately, the go project provides a tool that checks for those direct and indirect calls to help developers better focus their time instead of applying needless updates: govulncheck.

Running govulncheck in the most recent cassandra:latest image only shows one defect in gosu (which I will come back to). Any other CVEs given by other tools do not affect gosu since they are not in the execute path and,as far as I know, the defective functions are not even present in the binary. So they can all be ignored or VEXed away.

So, the one defect that does come up GO-2023-1840 (aka CVE-2023-29403) looks like it has mitigations already in place.

On Unix platforms, the Go runtime does not behave differently when a binary is run with the setuid/setgid bits

1. the gosu binary in the cassandra image is not setuid or setgid
2. gosu also has specific code to prevent running under setuid or setgid: https://github.com/tianon/gosu/blob/b73cc93b6f5b5a045c397ff0f75190e33d853946/main.go#L53-L59

$ docker pull cassandra
Using default tag: latest
latest: Pulling from library/cassandra
31bd5f451a84: Pull complete
32b311b806c8: Pull complete
23f2664f4576: Pull complete
e028f15ee70b: Pull complete
66b307664f73: Pull complete
908bad5be6da: Pull complete
dbd0aba0896e: Pull complete
6d69b54fc45b: Pull complete
7ff89e14c6b6: Pull complete
b4e4e3cfa8e0: Pull complete
Digest: sha256:26d622115c340f0990e837a68d9159a411a4ae90017f4f786212e4732300ecaa
Status: Downloaded newer image for cassandra:latest
docker.io/library/cassandra:latest
$ docker run -it --rm cassandra bash
root@921d68994a65:/# apt update
...
Fetched 29.4 MB in 7s (4,366 kB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.
root@921d68994a65:/# apt install golang --no-install-recommends
...
root@921d68994a65:/# go install golang.org/x/vuln/cmd/govulncheck@latest
...
root@921d68994a65:/# /root/go/bin/govulncheck --mode=binary /usr/local/bin/gosu
Scanning your binary for known vulnerabilities...

Vulnerability #1: GO-2023-1840
    Unsafe behavior in setuid/setgid binaries in runtime
  More info: https://pkg.go.dev/vuln/GO-2023-1840
  Standard library
    Found in: runtime@go1.18.2
    Fixed in: runtime@go1.19.10
    Example traces found:
      #1: runtime.Caller
      #2: runtime.CallersFrames
      #3: runtime.Frames.Next
      #4: runtime.Func.Entry
      #5: runtime.Func.Name
      #6: runtime.FuncForPC
      #7: runtime.GC
      #8: runtime.GOMAXPROCS
      #9: runtime.GOROOT
      #10: runtime.Gosched
      #11: runtime.LockOSThread
      #12: runtime.SetFinalizer
      #13: runtime.TypeAssertionError.Error
      #14: runtime.TypeAssertionError.RuntimeError
      #15: runtime.boundsError.Error
      #16: runtime.boundsError.RuntimeError
      #17: runtime.errorAddressString.Addr
      #18: runtime.errorAddressString.Error
      #19: runtime.errorAddressString.RuntimeError
      #20: runtime.errorString.Error
      #21: runtime.errorString.RuntimeError
      #22: runtime.lockRank.String
      #23: runtime.plainError.Error
      #24: runtime.plainError.RuntimeError
      #25: runtime.waitReason.String

Your code is affected by 1 vulnerability from the Go standard library.

Share feedback at https://go.dev/s/govulncheck-feedback.
root@921d68994a65:/# ls -l /usr/local/bin/gosu
-rwxr-xr-x 1 root root 2355690 Dec 20  2022 /usr/local/bin/gosu
root@921d68994a65:/# stat /usr/local/bin/gosu
  File: /usr/local/bin/gosu
  Size: 2355690         Blocks: 4608       IO Block: 4096   regular file
Device: 100002h/1048578d        Inode: 141912      Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2022-12-20 00:46:12.000000000 +0000
Modify: 2022-12-20 00:46:12.000000000 +0000
Change: 2024-02-03 00:20:10.106115573 +0000
 Birth: 2024-02-03 00:20:10.096115585 +0000

So, that's a long way of saying, "no, I don't see a need for us to rebuild gosu or seek an alternative for the cassandra images" (or in any image maintained in the docker-library namespace on GitHub).

[jhawkins1]

Thanks for the feedback, and I understand all that and agree. It comes down to folks having to spend time and effort justifying and providing evidence of false positives from industry scanners as part of vulnerability management programs to internal/external security auditors as to CVEs. That is normal practice, however, I would like to avoid doing that where possible. It comes down to spending effort on bureaucratic paperwork or effort spent to simply to get the maintainers to rebuild/maintain a component, I/we contribute changes or support to a project, or come up with alternative. If we have to keep justifying false positives due to the gosu project not wanting to perform what we consider a simple change, we will do that as I frankly don't want to spend effort forking away and maintaining a separate set of software from the mainstream projects. As to the usage of EOL version of GO, that cannot be justified -- not being accepted today -- to that the internal/external auditors say fix or replace the component. So, this comes down to convincing the projects to update/maintain or we have to fork away and maintain on our own in order to meet the requirements -- don't really want to fork.