fix: update runc dependency 5 patch versions to remediate vulnerabilities

[mmccard]

runc v1.1.2 and v1.1.5 fix about 2 dozen Common Vulnerabilities and Exposures.

tested locally with:

./build.sh
./test.sh ./gosu-amd64

[tianon]

Please read https://github.com/tianon/gosu/blob/a430ca0e1086cae8273b0187a8ffb52bf4c4d21c/SECURITY.md

[erickpeirson]

Please read https://github.com/tianon/gosu/blob/a430ca0e1086cae8273b0187a8ffb52bf4c4d21c/SECURITY.md

@tianon I read that document and, while I appreciate the need to stay focused on vulnerabilities that directly pertain to gosu itself, the practical reality is that users of the software often must grapple with CVEs pertaining to its dependencies. For example, Go prior to 1.19.10 is subject to several critical vulnerabilities, and mainstream scanners will therefore flag gosu itself as vulnerable.

Is the expectation that users of the software will simply have to build their own binaries of gosu using a more recent version of Go?

[yosifkit]

The gosu binaries are not vulnerable even through those dependencies and scanners that report them are wrong. Their dependency version comparison method is fine for a broad approach, but more nuance is required. The creator and maintainer of this project has said that those CVE's do not apply. They know what code paths are possible and govulncheck has programmatically verified this.

I would guess that the expectation is that scanners will get better and use deeper static analysis, like Go's govulncheck tooling, that shows certain CVE's being non-applicable. In absence of that @tianon has provided a script that runs govulncheck that will check if there are applicable CVE's and then users can tell their scanner that they don't apply.

[erickpeirson]

The gosu binaries are not vulnerable even through those dependencies and scanners that report them are wrong.

Perhaps they are wrong, but if so that's likely a contingent fact. It is certainly possible in principle for a vulnerability to impact a language like Go in a way that produces a vulnerable binary from otherwise flawless source code.

Theoretical issues aside, the practical reality is that a very significant number of users are beholden to scanners that pay attention to dependencies (including the language). Right now gosu binaries are built with a particular version of Go, that version of Go has critical vulnerabilities associated with it, and so users must make a choice: maintain their own build pipeline for gosu, or don't use gosu.

If the answer is that users are expected to maintain the build themselves, that's fine. But important to be clear-eyed and explicit about it.

[tianon]

Security scanners should improve to remove this busywork from the industry. If gosu is actually vulnerable to something, I will take that report seriously, but just "the version numbers happen to include a vulnerability elsewhere in unused, unrelated, uninvoked, and thus unincluded by the compiler code" is not compelling to me, sorry.

You might enjoy opencontainers/runc#3998 (comment) however, which is a proposal which will involve the code we import from runc moving to the pure library module github.com/moby/sys instead, which when we move, should address your concern as a side effect.

[erickpeirson]

Look, fine to draw the line wherever you like. But it's important to have a clear-eyed view of what that means for users. Practically speaking, what this means for us is that we will have to compile gosu ourselves in the short-term using a more recent version of Go, and ultimately not use gosu at all in the long-term since this posture toward vulnerabilities isn't compatible with deploying into enterprise environments.

[tianon]

There's a mismatch in the use of the word "vulnerability" here: gosu itself is not vulnerable. It happens to use a library which has some code in it that has a defect (which again, does not affect gosu).

[erickpeirson]

Please reread my last comment. This is feedback, offered in good faith. Feel free to ignore, but recognize that others can't.

[ryan-shaw]

I think I unfortunately agree with @erickpeirson here, someone from InfoSec can run any security scanner on any docker image we build and they are thrown a list of "high" and "critical" CVEs all coming from this package, they aren't going to easily buy "trust me it's fine" especially when they pay for the tools that detect these issues.