gosu vulnerabilities and usage of End-of-Life Version of GO #276
Comments
|
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: Running So, the one defect that does come up GO-2023-1840 (aka
$ 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: [email protected]
Fixed in: [email protected]
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 |
|
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. |
|
I came across this when searching for a fix for a critical CVE reported for golang stdlib: https://scout.docker.com/vulnerabilities/id/CVE-2024-24790 It's unfortunate if there's not an up-to-date release of gosu that fixes this problem since it adds a great burden to maintainers of systems using gosu - by searching for the evidence, justifying and documenting exclusions. I found this public note: https://github.com/tianon/gosu/blob/master/SECURITY.md
That's good to know but hardly solves my problem. Out of curiosity, I tried to follow the steps outlined in @yosifkit 's post: #276 (comment) If gosu doesn't use interfaces like net/http which all these CVEs are reported here? |
|
I'm not able to reproduce your result (I get the same as yosifkit did) -- can you please elaborate on a better reproducer? $ docker run -it --rm --pull=always cassandra bash
latest: Pulling from library/cassandra
Digest: sha256:9194f97b286a47a537281e8ca5e1e2d90686624d28264f669bd87799c58a3e67
Status: Image is up to date for cassandra:latest
root@c81003a7f5ae:/# apt update -qq
1 package can be upgraded. Run 'apt list --upgradable' to see it.
root@c81003a7f5ae:/# apt install -yqq --no-install-recommends golang-1.21-go # "golang-go" gives us 1.18 which isn't new enough for govulncheck
The following additional packages will be installed:
golang-1.21-src
Suggested packages:
bzr | brz git mercurial subversion
Recommended packages:
g++ gcc libc6-dev pkg-config
The following NEW packages will be installed:
golang-1.21-go golang-1.21-src
0 upgraded, 2 newly installed, 0 to remove and 1 not upgraded.
Need to get 44.5 MB of archives.
After this operation, 219 MB of additional disk space will be used.
debconf: delaying package configuration, since apt-utils is not installed
Selecting previously unselected package golang-1.21-src.
(Reading database ... 8687 files and directories currently installed.)
Preparing to unpack .../golang-1.21-src_1.21.1-1~ubuntu22.04.2_all.deb ...
Unpacking golang-1.21-src (1.21.1-1~ubuntu22.04.2) ...
Selecting previously unselected package golang-1.21-go.
Preparing to unpack .../golang-1.21-go_1.21.1-1~ubuntu22.04.2_amd64.deb ...
Unpacking golang-1.21-go (1.21.1-1~ubuntu22.04.2) ...
Setting up golang-1.21-src (1.21.1-1~ubuntu22.04.2) ...
Setting up golang-1.21-go (1.21.1-1~ubuntu22.04.2) ...
root@c81003a7f5ae:/# /usr/lib/go-1.21/bin/go install golang.org/x/vuln/cmd/govulncheck@latest
go: downloading golang.org/x/vuln v1.1.2
go: downloading golang.org/x/telemetry v0.0.0-20240522233618-39ace7a40ae7
go: downloading golang.org/x/tools v0.22.0
go: downloading golang.org/x/mod v0.18.0
go: downloading golang.org/x/sync v0.7.0
root@c81003a7f5ae:/# /root/go/bin/govulncheck -mode=binary /usr/local/bin/gosu
=== Symbol Results ===
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: [email protected]
Fixed in: [email protected]
Vulnerable symbols found:
#1: runtime.Caller
#2: runtime.CallersFrames
#3: runtime.Frames.Next
#4: runtime.Func.Entry
#5: runtime.Func.Name
Use '-show traces' to see the other 20 found symbols
Your code is affected by 1 vulnerability from the Go standard library.
This scan also found 3 vulnerabilities in packages you import and 41
vulnerabilities in modules you require, but your code doesn't appear to call
these vulnerabilities.
Use '-show verbose' for more details. |
|
@tianon sorry, this is problably a wrong place for my report I just found this when searching for gosu vulnerabilities. Anyway, here's how you can reproduce it using public If, after installing gosu, I export the docker image of the current version of the container and run docker scout on it, then it reports the vulnerabilities I'm concerned about |
$ docker run ubuntu:noble -it /bin/bash
# inside the container
$ apt update && apt install gosu
$ gosu --version
1.17 (go1.21.3 on linux/arm64; gc)@jumarko, that looks like something to bring up with Canonical since they are the ones controlling the packaging and version of Go that is building that |
|
@yosifkit thanks for the tip - I reported it here https://bugs.launchpad.net/cloud-images/+bug/2072883 (private). |
|
I'll open up the cloud-images bug. there is no need for it to be private as the CVE is already disclosed and fixed in multiple golang versions. i'll also work on directing things to the correct locations -- it's not a Docker or cloud-images bug |
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?
The text was updated successfully, but these errors were encountered: