Open dims opened 1 week ago
Etcd pkg Insecure ciphers are allowed by default in go.etcd.io/etcd/client/pkg/v3
is mentioned in https://pkg.go.dev/vuln/GO-2024-2527.
Insecure cipher suite is indeed allowed in etcd client pkg. Pls refer to client/pkg/tlsutil/cipher_suites.go#L30-L34. Users can configure it using the flag --cipher-suites
, and a safe default list is used if empty.
So the GO-2024-2527 is still valid, but I think the severity is low, so no any action is required. Also Note that TLS 1.3 ciphersuites are not configurable.
Incorrect assessment of the published security errata - Indicates that it's already addressed in specific versions (refer screenshot); also, --cipher-suites
is an argument that the etcd
server has nothing to do with dependent libraries of using etcd clients.
Whoever updated the Go vulnerability must revert it. Otherwise, we need to stop using this tool altogether, as it's no longer reliable.
We need to update github.com/etcd-io/etcd/security/advisories/GHSA-5x4g-q5rc-36jp.
Not sure whether the github.com/advisories/GHSA-5x4g-q5rc-36jp will be automatically updated after we update the etcd/security/advisories/GHSA-5x4g-q5rc-36jp
.
cc @jmhbnz @serathius @spzala @wenjiaswe @dims
Thank you for the report. We will look into this.
So, how to handle this vuln rn?
Change https://go.dev/cl/595995 mentions this issue: data/reports: withdraw GO-2024-2527
Thank you all for reporting this issue. The report has been withdrawn and should be live in 10-15 minutes.
Thanks.
We are going to update the security advisory per option 2 mentioned in https://docs.google.com/document/d/1Pl2e8YTtgt3pYeIZSXJIn4gknp6tTW14htMat1JaM4k/edit#heading=h.keepbsj3ympp
To give some insight into why this report was published: we are experimenting with expanding the Go vulnerability database's scope to include vulnerabilities that primarily affect Go binaries as well as libraries. To support this increased scope, we need to automatically generate more reports. In this case, our automation saw two patched versions - v3.4.10 and v3.3.23 - in github.com/advisories/GHSA-5x4g-q5rc-36jp but these patched versions do not exist in go.etcd.io/etcd/client/pkg/v3 according to the Go module proxy (https://pkg.go.dev/go.etcd.io/etcd/client/pkg/v3?tab=versions). We thus conservatively reported all versions as being affected.
@ahrtr if you would like us to un-withdraw the report with updated version info in the future, we are happy to.
@ahrtr if you would like us to un-withdraw the report with updated version info in the future, we are happy to.
Ideally we should mark the CVE being resolved in 3.4.22, and 3.5.0 and onwards aren't affected at all.
But it's also OK to withdraw the report. We are good as long as we can remove the security noise (false positives).
but these patched versions do not exist in go.etcd.io/etcd/client/pkg/v3 according to the Go module proxy (https://pkg.go.dev/go.etcd.io/etcd/client/pkg/v3?tab=versions)
The reason is etcd release-3.4 and release-3.5/main have big difference regarding code structure. The go.etcd.io/etcd/client/pkg/v3
doesn't exist in release-3.4.
FYI. we just updated the security advisory below. Thanks all!
@ahrtr We (vulndb) need to decide if we are going to keep this withdrawn going forward. It would be helpful to confirm the history of how etcd evolved for us to decide this.
From Go's perspective there are 4 relevant modules:
From what I can tell:
cipherSuites
global variable defined in pkg/tlsutil/cipher_suites.go .tlsutil
. Any transitive importer of the package would be warned.client/pkg
.v0.5.0
.go.etcd.io/etcd
as pseudo-versions, e.g. v3.4.21 would be v0.5.0-alpha.5.0.20220915004622-85b640cee793
.First, is all of the above history correct?
Assuming it is, here are the three options vulndb is deciding between:
v3.4.22
.Do you have any opinions about options 2 and 3, or a strong preference amongst these?
Note that the difference between 2 and 3 is just not warning for those synced past the date 20220915004622 (not the semver or the git tag. the date of the git commit). I expect this to only impact folks that have not upgraded >=3.4.22. I would expect option 2 to warn users of v3.4.23 through v3.4.33. v3.4.33 was published July 13, 2034 (a couple of weeks ago). (So presumably someone is using this?) I manually checked that git tags v3.4.23 through v3.4.33 are past the date 20220915004622. Option 3 has a small [theoretical?] risk of false positives. To receive a false positive, would require a new version [go.etcd.io/etcd](http://go.etcd.io/etcd)
to be published in the future (say v3.4.50) that does not contain the vulnerable code with a git commit date before this (several years in the past).
I am currently leaning towards pursuing Option 3 at the moment. The chances of false positives with a date range seem low to me. If this shows itself to be problematic, there is an option of withdrawing again (after some user annoyance that we want to avoid).
I get that this is mostly a “vulndb problem”, but I am hoping to get some feedback from etcd before we un-withdraw the vulnerability for a more accurate report.
@timothy-king I appreciate the detailed analysis!
From what I can tell:
- The relevant code of the vulnerability is using the
cipherSuites
global variable defined in pkg/tlsutil/cipher_suites.go .- This global appears in git tags up to v3.4.21: https://github.com/etcd-io/etcd/blob/v3.4.21/pkg/tlsutil/cipher_suites.go . Due to limits of the tool, for vulndb to report anything, it is going to mark the entire package for
tlsutil
. Any transitive importer of the package would be warned.- The global was removed in the git tag v3.4.22. (I am being picky here as I need to distinguish git vs. the Go module.)
- The files for the package but not the global moved to
client/pkg
.- go.etcd.io/etcd/v3 started at v3.5.0 (technically v3.5.0-alpha.0) and has never had this package.
- go.etcd.io/etcd/pkg/v3 started at v3.5.0 and has never had this package.
- go.etcd.io/etcd/client/pkg/v3 started at v3.5.0 and the package did move there, but not the global.
- go.etcd.io/etcd module last tagged version that is directly 'go gettable' was 'v3.3.27+incompatible'. The last compatible semver with Go is
v0.5.0
.- Someone can with some effort download the module
go.etcd.io/etcd
as pseudo-versions, e.g. v3.4.21 would bev0.5.0-alpha.5.0.20220915004622-85b640cee793
.First, is all of the above history correct?
Yes, correct.
Assuming it is, here are the three options vulndb is deciding between:
- Leave the vulnerability as withdrawn.
- Unwithdraw the vulnerability, but warn all transitive users of the package go.etcd.io/etcd/pkg/tlsutil within the module go.etcd.io/etcd (no v3!) on all versions. No other modules will be warned on.
- Unwithdraw the vulnerability, but warn all transitive users of the package go.etcd.io/etcd/pkg/tlsutil within the module go.etcd.io/etcd (no v3!), until the pseudo version for
v3.4.22
.Do you have any opinions about options 2 and 3, or a strong preference amongst these?
Either option 1 or 3 works for me. We are good as long as we can clear the false positive.
Honestly, we (etcd) simply inappropriately defined a global variable cipherSuites in etcd v3.4.21 and older versions, but I don't think we (etcd) should raise the security advisory https://github.com/etcd-io/etcd/security/advisories/GHSA-5x4g-q5rc-36jp in the first place because the behaviour has never changed from user perspective (refer to doc),
Report ID
GO-2024-2527
Suggestion/Comment
etcd advisory - https://github.com/etcd-io/etcd/security/advisories/GHSA-5x4g-q5rc-36jp
etcd 3.5.x series was never affected by this vulnerability as 3.5.0 was released about a year after the 3.4.x branch was fixed. So the following error message is wrong (
Fixed in: N/A
)3.5.0 release tag info - https://github.com/etcd-io/etcd/tree/v3.5.0 3.4.10 release tag info - https://github.com/etcd-io/etcd/tree/v3.4.10