Hide Forgot
A flaw was found in the amd64 implementation of the golang.org/x/crypto/salsa20 and golang.org/x/crypto/salsa20/salsa. If more than 256 GiB of keystream is generated, or if the counter otherwise grows greater than 32 bits, the amd64 implementation will first generate incorrect output, and then cycle back to previously generated keystream. Repeated keystream bytes can lead to loss of confidentiality in encryption applications, or to predictability in CSPRNG applications. Upstream patch: https://go.googlesource.com/crypto/+/b7391e95e576cacdcdd422573063bc057239113d References: https://groups.google.com/forum/#!msg/golang-announce/tjyNcJxb2vQ/n0NRBziSCAAJ
Created golang-googlecode-go-crypto tracking bugs for this issue: Affects: epel-all [bug 1691531] Affects: fedora-all [bug 1691530] Created gomtree tracking bugs for this issue: Affects: fedora-all [bug 1691532] Created source-to-image tracking bugs for this issue: Affects: fedora-all [bug 1691533]
Notes on if gomtree is impacted: gomtree upstream: https://github.com/vbatts/go-mtree (gomtree is just the cli output binary, see cmd/gomtree) gomtree includes nacl box. (https://godoc.org/golang.org/x/crypto/nacl/box) nacl box includes "golang.org/x/crypto/salsa20/salsa". Can't find any uses of salsa or box in the actual gomtree source code. Grepping strings in the binary shows no instances of these either. I think the salsa20 is just an artifact. sals20 was deleted upstream in this commit: https://github.com/vbatts/go-mtree/commit/94a6c46bde3ce60a3ea448136730e5c331eed85b I think glide was pulling in all of salsa via this in glide.yaml: import: - package: golang.org/x/crypto subpackages: - ripemd160 Unclear where box was coming from. Nevertheless, I believe gomtree isn't affected.
Same thing with source-to-image. Salsa20 looks to be a dependency, but I believe that is because it's pulling down x/crypto again. ``` - package: golang.org/x/crypto version: 81e90905daefcd6fd217b62423c0908922eadb30 ``` I didn't find any usages of it in the code after a quick glance.
mongodb 3.4 looks unaffected. crypto lib only appears to be used in ./common/password/pass_util.go. Godeps pulls down all of crypto to the best of my knowledge. `golang.org/x/crypto 1f22c0103821b9390939b6776727195525381532 github.com/golang/crypto`
Same result for mongodb 3.6.3
Same result for mongo-tools. Pulls down crypto deps, doesn't appear to make use of salsa20.
Fixed in origin in 4.3.0: https://github.com/openshift/ose/commit/8d2e856da783717a9efae4a8b9d373f8dac45192
External References: https://groups.google.com/forum/#!msg/golang-announce/tjyNcJxb2vQ/n0NRBziSCAAJ
This issue has been addressed in the following products: Red Hat OpenShift Container Platform 3.11 Via RHSA-2021:0079 https://access.redhat.com/errata/RHSA-2021:0079
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2019-11840