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"

[yosifkit]

• CVE-2022-2879 : Reader.Read does not set a limit on the maximum size of file headers. A maliciously crafted archive could cause Read to allocate unbounded amounts of memory, potentially causing resource exhaustion or panics. After fix, Reader.Read limits the maximum size of header blocks to 1 MiB.
• CVE-2022-41715: Programs which compile regular expressions from untrusted sources may be vulnerable to memory exhaustion or denial of service. The parsed regexp representation is linear in the size of the input, but in some cases the constant factor can be as high as 40,000, making relatively small regexps consume much larger amounts of memory. After fix, each regexp being parsed is limited to a 256 MB memory footprint. Regular expressions whose representation would use more space than that are rejected. Normal use of regular expressions is unaffected.
• CVE-2022-2880 : Requests forwarded by ReverseProxy include the raw query parameters from the inbound request, including unparseable parameters rejected by net/http. This could permit query parameter smuggling when a Go proxy forwards a parameter with an unparseable value. After fix, ReverseProxy sanitizes the query parameters in the forwarded query when the outbound request's Form field is set after the ReverseProxy. Director function returns, indicating that the proxy has parsed the query parameters. Proxies which do not parse query parameters continue to forward the original query parameters unchanged.

Can you please take a look if these are false positives as well ? Thanks

1. gosu doesn't open archives
2. gosu doesn't "compile regular expressions from untrusted sources"
3. gosu doesn't make or receive any http(s) requests

[tianon]

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).

[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 govulncheck@v0.0.0 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.