Vulnerabilities in gosu

[anksvault]

Our scanner has identified gosu code vulnerable with CVE-2023-27561 and CVE-2023-28642.

Following is the result from govulncheck tool scan on gosu binary.

Using [email protected] with
vulnerability data from https://vuln.go.dev/ (last modified 2023-06-22 16:44:55 +0000 UTC).

Scanning your binary for known vulnerabilities...
Your code is affected by 1 vulnerability from the Go standard library.

Vulnerability #1: GO-2023-1840
On Unix platforms, the Go runtime does not behave differently
when a binary is run with the setuid/setgid bits. This can be
dangerous in certain cases, such as when dumping memory state,
or assuming the status of standard i/o file descriptors. If a
setuid/setgid binary is executed with standard I/O file
descriptors closed, opening any files can result in unexpected
content being read or written with elevated privileges.
Similarly, if a setuid/setgid program is terminated, either via
panic or signal, it may leak the contents of its registers.

More info: https://pkg.go.dev/vuln/GO-2023-1840

Standard library
Found in: [email protected]
Fixed in: [email protected]

[tianon]

As correctly determined by govulncheck, we do not invoke the code from runc which is vulnerable to either of those CVEs.

Regarding GO-2023-1840, we very actively discourage running with the setuid bit on gosu, so we've already got alternate mitigation in place for that:

gosu/main.go

Lines 51 to 56 in 4f8f387

	if fi, err := os.Stat("/proc/self/exe"); err != nil {
	log.Fatalf("error: %v", err)
	} else if fi.Mode()&os.ModeSetuid != 0 {
	// ... oh no
	log.Fatalf("error: %q appears to be installed with the 'setuid' bit set, which is an *extremely* insecure and completely unsupported configuration! (what you want instead is likely 'sudo' or 'su')", os.Args[0])
	}

I do need to spend some time thinking about how best to quiet this in govulncheck since they don't (to my knowledge) support any means of quieting detections. 😞

Edit: very relevant: golang/go#59507

[anksvault]

Thank you for your comments. Can you please confirm if - "we do not invoke the code from runc which is vulnerable to either of those CVEs" means that gosu doesn't have the vulnerable runc code at all or gosu still contains the vulnerable runc code but is not used in gosu?

My security team is insisting we get the issue resolved ASAP because it is highlighted as a vulnerability in our image. Is there a plan to upgrade runc version used in gosu anytime soon? Also, can you please confirm if a new gosu version with a higher runc version won't be released then, are there instructions to build a customized version of gosu with a higher runc version? This could be our workaround to keep the security team calm.

[tianon]

Both of those CVEs are false positives, and should be reported to your security scanner vendor as such.

[anksvault]

Both of those CVEs are false positives, and should be reported to your security scanner vendor as such.

I understand this based on your SECURITY.md instructions and i have already done this however, the scanner vendor and security team claims that if the vulnerable code is present in the binary, it should still be available for an attacker to compromise the system. This is why I need your confirmation/response to my last query.

[tianon]

The code is not present (that's literally what govulncheck validates and why I prefer it to traditional scanning tools).

[tianon]

New PR at #129 to ignore/exclude GO-2023-1840 (aka CVE-2023-29403) from our reporting.