CVEs that do not apply to gosu

[tianon]

NOTE: this list is no longer actively maintained; see #104 (comment):

With https://github.com/tianon/gosu/releases/tag/1.15, I've now got https://github.com/tianon/gosu/blob/master/SECURITY.md which makes it clear how to determine whether vulnerabilities apply to a released version/build of gosu (TLDR, the answer is now govulncheck, which checks for invocations of the actual vulnerable functionality).

---

CVEs that do not apply to builds of gosu:

• CVE-2019-11254: ... gosu is not Kubernetes (and does not parse YAML) (#105)
• CVE-2020-14039: does not use certificates (docker-library/mongo#529)
• CVE-2020-15586: does not use net/http (docker-library/mongo#529)
• CVE-2020-16845: does not use encoding/binary (docker-library/mongo#529)
• CVE-2020-24553: does not use text/html or CGI/FCGI (docker-library/mongo#529)
• CVE-2020-28362: does not use math/big (docker-library/mongo#529)
• CVE-2020-28366: vulnerability in cmd/go, not Go programs (docker-library/mongo#529)
• CVE-2020-28367: vulnerability in cmd/go, not Go programs (docker-library/mongo#529)
• CVE-2021-27918: does not use encoding/xml (docker-library/mongo#529)
• CVE-2021-29923: does not parse IP addresses (#91, docker-library/mongo#529)
• CVE-2021-31525: does not use net/http (docker-library/mongo#529)
• CVE-2021-33194: does not use golang.org/x/net (#107)
• CVE-2021-33195: does not perform DNS lookups (docker-library/mongo#529)
• CVE-2021-33196: does not use archive/zip (#94, docker-library/mongo#529)
• CVE-2021-33197: does not use net/http/httputil (docker-library/mongo#529)
• CVE-2021-33198: does not use math/big (docker-library/mongo#529)
• CVE-2021-36221: does not use net/http/httputil (docker-library/mongo#529)
• CVE-2021-38297: does not (could not?) support GOARCH=wasm (#98, docker-library/mongo#529)
• CVE-2021-39293: does not use archive/zip (#94, #97, #101, docker-library/mongo#529)
• CVE-2021-41771: does not use debug/macho (#98, docker-library/mongo#529)
• CVE-2021-41772: does not use archive/zip (docker-library/mongo#529)
• CVE-2021-43784: vulnerable runc code not used (#100)
• CVE-2021-44716: does not use net/http (#98, docker-library/mongo#529)
• CVE-2022-1705: does not use net/http (#112)
• CVE-2022-1962: no deeply nested types (#112)
• CVE-2022-23772: does not use math/big (#103)
• CVE-2022-23773: vulnerability in cmd/go, not Go programs (#99)
• CVE-2022-23806: does not use crypto/elliptic (#99)
• CVE-2022-24675: does not use encoding/pem (#108)
• CVE-2022-24769: does not change process capabilities (#115)
• CVE-2022-24921: does not use deeply nested regexp (#107)
• CVE-2022-27191: does not use golang.org/x/crypto/ssh (#108)
• CVE-2022-27664: does not use net/http
• CVE-2022-28131: does not use encoding/xml (#112)
• CVE-2022-28327: does not use crypto/elliptic (#108)
• CVE-2022-29162: does not change process capabilities (#109)
• CVE-2022-29526: does not use Faccessat
• CVE-2022-30580: does not (could not?) support GOOS=windows (#112)
• CVE-2022-30629: does not use crypto/tls (#112)
• CVE-2022-30630: does not use file globbing (#112)
• CVE-2022-30631: does not use compress/gzip (#112)
• CVE-2022-30632: does not use file globbing (#112)
• CVE-2022-30633: does not use encoding/xml (#112)
• CVE-2022-30635: does not use encoding/gob
• CVE-2022-32189: does not use math/big

If you use (or maintain) a security scanner which reports any of these against gosu, please report them to the security vendor as false positives.

(See also https://snarky.ca/the-social-contract-of-open-source/)

[HeyImAllan]

Dear @tianon,

I would like to respectfully ask if there are any plans on life cycling the golang packages in the near future?

Thank you.

[tianon]

I try to keep the main development branch up-to-date with newer package versions, but I have no plans to make a new release of gosu unless there is a compelling reason to do so (changes to/CVEs in the actual codepaths gosu invokes, changes to gosu itself, etc).

[yuriy-yarosh]

@tianon please make a minor 1.15 release to update the runc to 1.1.2 and make people happy.
golang.org/x/sys should be also updated to 0.0.0-20220412211240-33da011f77ad, according to trivy.

CVE wise I'm getting only two that actually bother me a bit CVE-2022-29162 / CVE-2022-29526

[tianon]

• CVE-2022-29526: does not use Faccessat
• CVE-2022-29162: does not change process capabilities

[slakwa]

@tianon can you take a look at CVE-2022-30635? Our scanner started to show it lately.

[tianon]

• CVE-2022-30635: does not use encoding/gob

[ZimboQC]

Hi @tianon , Prisma found two new vulnerabilities :

• CVE-2022-32189: A too-short encoded message can cause a panic in Float.GobDecode and Rat GobDecode in math/big in Go before 1.17.13 and 1.18.5, potentially allowing a denial of service. More detail at https://nvd.nist.gov/vuln/detail/CVE-2022-32189
• CVE-2022-27664: In net/http in Go before 1.18.6 and 1.19.x before 1.19.1, attackers can cause a denial of service because an HTTP/2 connection can hang during closing if shutdown were preempted by a fatal error. More detail at https://nvd.nist.gov/vuln/detail/CVE-2022-27664

Can you take a look? Thanks!

[tianon]

similar to many of the CVEs that are listed, "does not use math/big" / "does not use net/http"

[ThomasKroghMortensen]

@tianon
Based on above mentioned https://github.com/tianon/gosu/blob/master/SECURITY.md, I see that two out of three new CVEs are not affecting [CVE-2022-32148, CVE-2022-41717], but the last one [CVE-2022-41716] is not covered, since it relates to Go os/exec?

CVE-2022-32148 is a net/http, so this is according to readme not affecting.
CVE-2022-41717 is a net/http, so this is according to readme not affecting.

CVE-2022-41716 is a os/exec - So does it mean it is affecting?

[tianon]

Please run govulncheck on the binary to verify.

[ThomasKroghMortensen]

Thanks.

FYI:

# /gosu --version1.16 (go1.18.2 on linux/amd64; gc)
# govulncheck /gosu
govulncheck is an experimental tool. 
Share feedback at https://go.dev/s/govulncheck-feedback.
Scanning for dependencies with known vulnerabilities...
No vulnerabilities found.

# /gosu14 --version1.14 (go1.16.7 on linux/amd64; gc)
# govulncheck /gosu14
govulncheck is an experimental tool. 
Share feedback at https://go.dev/s/govulncheck-feedback.
Scanning for dependencies with known vulnerabilities...
govulncheck: vulncheck.Binary: binary built using unsupported Go Version: go1.16.7 

All fine - we will use redis 7.0.8 with gosu 1.16. (1.14 where where we had the CVEs), but we will upgrade to be sure.

[tianon]

$ ./gosu-amd64 --version
1.16 (go1.18.2 on linux/amd64; gc)

$ go install golang.org/x/vuln/cmd/govulncheck@latest
go: downloading golang.org/x/vuln v0.0.0-20230331150530-a42f9910daf3
go: downloading golang.org/x/mod v0.9.0
go: downloading golang.org/x/tools v0.7.0
go: downloading golang.org/x/sys v0.6.0

$ govulncheck ./gosu-amd64
govulncheck is an experimental tool. Share feedback at https://go.dev/s/govulncheck-feedback.

Using [email protected] with
vulnerability data from https://vuln.go.dev (last modified 2023-03-29 14:45:38 +0000 UTC).

Scanning your binary for known vulnerabilities...
No vulnerabilities found.

[ganshnec1030]

HI @tianon

Thank you for your time and response.

Just want to double-check, govulncheck is not showing CVE-2022-32190 CVE, so can we mark it as false positive?

[tianon]

Please read https://github.com/tianon/gosu/blob/6a1967c98c3d1854dd29f32433f1e0c59b244c5f/SECURITY.md again, especially the third paragraph.

[thekaibosh]

@tianon would you add CVE-2023-28642 to this list please? I appreciate your position on CVEs related to go. I've got my SecOps team onboard with using this issue as justification for dismissing/reporting false postives

[tianon]

Unfortunately, no, I will not be updating/maintaining this list. I made a lot of changes to the way I build/release in support of the updated security policy (https://github.com/tianon/gosu/blob/master/SECURITY.md), in which I now treat the results of govulncheck as canonical because that tool is going to do a much more thorough check of whether the functions gosu actually invokes are affected by a given vulnerability than I could possibly do myself (and in addition, I now run govulncheck on gosu at least weekly via a scheduled GitHub Actions CI job, which is also public in this repository).

[daniel-brenot]

Can I just ask if there is something about updating to a new version of golang that poses more effort than updating all of these vulnerability tools? I understand that this project doesn't use the parts of the code that have the CVE at the moment, but I can't help but wonder if it is less effort to just update the go version than it is to ask all of the tools to ignore the warnings for this tool.

[CRCinAU]

Can I just ask if there is something about updating to a new version of golang that poses more effort than updating all of these vulnerability tools? I understand that this project doesn't use the parts of the code that have the CVE at the moment, but I can't help but wonder if it is less effort to just update the go version than it is to ask all of the tools to ignore the warnings for this tool.

This would be nice. The thousands of people marking (currently) 52 "fixable" vulnerabilities as "yeah, its ok in this specific image" and potentially breaking things by "oh yeah, don't need to care about that" on packages that it actually does matter.

It's like training users to "Just click OK" or "Just allow it to elevate privs"...

However, if the author doesn't want to do that on behalf of their userbase, we can't force them.

[tianon]

If we, as the userbase of these "security scanning" tools, continue to accept the frankly poor status quo in the face of information/tooling that can trivially improve their false positive rates (govulncheck), nothing will improve. I'm not asking anyone to mark them as ignored (nor suggesting that anyone should do so) -- I'm asking you to actively report them to your scanner vendor as false positives and suggesting (demanding?) that they incorporate govulncheck into their tooling so that the situation can actually improve in a way that helps everyone using and writing Go-based tooling.

[daniel-brenot]

I understand your stance on this and appreciate it, but the end result here is that in the meantime everyone relying on this tool is having to constantly make security exceptions at their workplace. I do agree that the companies should fix their scanning(looking at you jfrog!), but this stance is involving everyone else here in the software politics, whether they like it or not.

At the end of the day this library is maintained by you and no one can force your hand, and you don't owe it to any of us. However you are passing software politics off to users who are dealing with this transitively and can't really opt out. In my case it's through a docker image that uses this and I don't have a good alternative to this library, so I'm stuck marking this as an exception.

As a thought of another way to approach this, updating the go libraries and making a new release is quite trivial to do and would make this vulnerability error go away for a large number of people for quite a while. If you want vulnerability scanning companies to make the exception and feel so strongly about it, I'd suggest that you yourself reach out to them with this suggestion. I promise you that jfrog does not care how many users complain about this issue, since at the end of the day they are just the most convenient solution for many people and have no reason to invest this effort into adding security scanning.

[CRCinAU]

I too totally understand your point. There is absolutely nothing wrong with it on a completely technical level. However we don't live in a completely technical world.

What it does do is to shift the burden onto the end users - of which, a percentage will end up here - and you'll waste even more time and brainpower in explaining all this to a newer set of users - again, and again, and again, and again. That's a lot of effort just to maintain the moral high-ground.

That same shift of burden ripples down to thousands of tech folks and thousands of projects. They too have to field these questions - because, say, Postgres will show (at least) 52 security vulnerabilities because of your stance on things. I'm sure the postgres guys in this scenario would prefer they didn't have to do this all the time as well.

The true cost and impact would be in the thousands of man hours - collectively, years of human effort to maintain this status quo. Myself? I'd rather be doing other things than trying to figure out which CVE relates to what component, if it matters for every one of the thousands of libraries that are present in modern day systems and be happier in life going "Yep, we're looking good" instead of writing exceptions, explaining to management why it never says "No security vulnerabilities" - and essentially training other staff by these actions that security vulnerability lists are there to be ignored - the subtlety there is dangerous long term.

Now, I don't have any skin in the game anymore - it was less effort for me personally to rip out gosu from my container and install a smaller, OS provided package that achieved the same end result as I needed - however mine was a VERY simple use case.

What I did do, was see what I saw to be a very strange stance that puzzled me as to why this was the case - and I've been grinding out code and systems for about 25 years now.

All that being said, I think you're dead wrong to defend sticking to an EOL version of GO and really hope that you at least keep things within supported versions - as security reports very rarely end up being published / accepted on EOL software - so you could no longer guarantee that any other tools you use would be updated to reflect reality once that magic EOL date passes.

I don't really expect any further replies - but would like @tianon to mull on these thoughts - as it does present somewhat of a mindset / culture shift on things. Just let it sit with you and peculate - like a good coffee :)