search

tianon / gosu

Simple Go-based setuid+setgid+setgroups+exec
Apache License 2.0
4.72k stars 320 forks source link

Vulnerabilities in gosu #128

Closed anksvault closed 1 year ago

anksvault commented 1 year ago

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 govulncheck@v0.0.0 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 https://github.com/tianon/gosu/issues/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: runtime@go1.18.2 Fixed in: runtime@go1.20.5

tianon commented 1 year ago

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:

https://github.com/tianon/gosu/blob/4f8f3870cfe41b372b8a66ea84476caca4751857/main.go#L51-L56

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. :disappointed:

Edit: very relevant: https://github.com/golang/go/issues/59507

anksvault commented 1 year ago

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 commented 1 year ago

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

anksvault commented 1 year ago

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 commented 1 year ago

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

tianon commented 1 year ago

New PR at https://github.com/tianon/gosu/pull/129 to ignore/exclude GO-2023-1840 (aka CVE-2023-29403) from our reporting.