yosifkit
commented
6 months ago 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
- the
gosubinary in thecassandraimage is not setuid or setgid gosualso 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 +0000So, 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
jumarko
tianon
j5awry
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?