crypto/internal/fips140: CVE-2022-29526 reported in golang.org/x/sys

[CameronGo]

I believe CVE-2022-29526 is already fixed in the current go version, however, when you download and extract the current Go v1.24.0, this CVE is reported due to the version of golang.org/x/sys reported in /usr/local/go/src/crypto/internal/fips140/bigmod/_asm/go.mod and /usr/local/go/src/crypto/internal/fips140/edwards25519/field/_asm/go.mod, which appears as follows:

go 1.19

require github.com/mmcloughlin/avo v0.4.0

require (
        golang.org/x/mod v0.4.2 // indirect
        golang.org/x/sys v0.0.0-20211030160813-b3129d9d1021 // indirect
        golang.org/x/tools v0.1.7 // indirect
        golang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1 // indirect
)

It looks as though someone tried to submit a PR to fix some time ago, but nothing happened with it. #62452

[ianlancetaylor]

In case it's not clear, there is no actual vulnerability here. The code you are describing is only used to generate other files in the standard library, it is not itself part of the standard library.

CC @golang/security @golang/release

[gabyhelp]

Related Issues

• fix(sec): upgrade golang.org/x/sys to 0.1.0 #62452 (closed)
• x/pkgsite: Versions tab showing fixed vulnerabilities for version-tagged x/ repos #56357 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[FiloSottile]

when you download and extract the current Go v1.24.0, this CVE is reported

This is a bug in the scanner. Is it reported by govulncheck or by a third-party tool?

[CameronGo]

when you download and extract the current Go v1.24.0, this CVE is reported

This is a bug in the scanner. Is it reported by govulncheck or by a third-party tool?

This is reported by AWS Inspector, not govulncheck, though I don't think the issue is as simple as "there's a bug in the scanner." The package version referenced in the go.mod does have the vulnerability. I realize that when a go binary is compiled, it reconciles the dependencies and will use the later version of whatever is referenced, so perhaps that what you're referring to and why the actual vulnerability is remediated, but we can't reasonably expect vulnerability scanners to literally run go version on every binary they encounter in order to verify vulnerability status. Part of maintaining a secure Internet is at least making reasonable attempts to play nice with security tools.

To me the better question is, why is the old / vulnerable version of that package still being referenced here and why must it remain that way?

[seankhliao]

As mentioned in prior comments, this only records dependencies for a code generation tool. It is a bug in your tooling to report a vulnerability on code that you will never execute or even be included in your dependency graph in any way.

[CameronGo]

As mentioned in prior comments, this only records dependencies for a code generation tool. It is a bug in your tooling to report a vulnerability on code that you will never execute or even be included in your dependency graph in any way.

The issue does not affect my applications, but rather the environments in which the applications are built. Every developer machine that has go installed will have this reference in their manifest and may be detected by vulnerability scanners as well as in images used by the CICD pipelines.

As I mentioned in my prior post, no one has offered an explanation as to why the reference cannot or should not be updated to a current version.

[ianlancetaylor]

I'm not opposed to updating the version, but why should we scramble to fix a non-existent security hole? We can turn the question around: no one has offered an explanation for why the scanners should not fix their false positive warning.

[CameronGo]

I'm not opposed to updating the version, but why should we scramble to fix a non-existent security hole? We can turn the question around: no one has offered an explanation for why the scanners should not fix their false positive warning.

Because, when tasked with building a scanner to identify vulnerabilities across an entire operating system and all of the applications installed, how do you expect such a scanner to function? You think it should govulncheck on the entire system? Or you think it should run go version on every binary just in case it was compiled in Go? The reality is, it's going use a hashing known bad binaries and text searches. How else would you propose such a thing to work?

What you're calling a bug in the scanner resulting in a false positive, I saw is totally reasonable and expected behavior from a security tool trying to help people identify stupid mistakes that introduce vulnerabilities into their system.

[ianlancetaylor]

The Go project has already provided a tool that does not have this kind of false positive. I expect security scanners to minimize false positives, and in this case we've already shown the way. False positives from security scanners are actively harmful, in that they encourage people to change existing, working, safe code. Such changes are more likely to introduce problems than to fix them.

As I said, I'm not opposed to updating the version.