-
Notifications
You must be signed in to change notification settings - Fork 17.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
crypto/elliptic: specific unreduced P-256 scalars produce incorrect results (CVE-2023-24532) #58647
Comments
We agreed with @rolandshoemaker that this can be fixed as PUBLIC since it only affects niche configurations, namely very specific direct uses of crypto/elliptic. We found no real world protocol that could be attacked due to this. |
Change https://go.dev/cl/471256 mentions this issue: |
Change https://go.dev/cl/471255 mentions this issue: |
@gopherbot please backport. CL 471255 is a security fix. /cc @golang/security and @golang/release |
Backport issue(s) opened: #58719 (for 1.19), #58720 (for 1.20). Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases. |
Change https://go.dev/cl/471695 mentions this issue: |
Change https://go.dev/cl/471696 mentions this issue: |
Unlike the rest of nistec, the P-256 assembly doesn't use complete addition formulas, meaning that p256PointAdd[Affine]Asm won't return the correct value if the two inputs are equal. This was (undocumentedly) ignored in the scalar multiplication loops because as long as the input point is not the identity and the scalar is lower than the order of the group, the addition inputs can't be the same. As part of the math/big rewrite, we went however from always reducing the scalar to only checking its length, under the incorrect assumption that the scalar multiplication loop didn't require reduction. Added a reduction, and while at it added it in P256OrdInverse, too, to enforce a universal reduction invariant on p256OrdElement values. Note that if the input point is the infinity, the code currently still relies on undefined behavior, but that's easily tested to behave acceptably, and will be addressed in a future CL. Updates #58647 Fixes #58720 Fixes CVE-2023-24532 (Filed with the "safe APIs like complete addition formulas are good" dept.) Change-Id: I7b2c75238440e6852be2710fad66ff1fdc4e2b24 Reviewed-on: https://go-review.googlesource.com/c/go/+/471255 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org> Run-TryBot: Filippo Valsorda <filippo@golang.org> Auto-Submit: Filippo Valsorda <filippo@golang.org> Reviewed-by: Damien Neil <dneil@google.com> (cherry picked from commit 203e59a) Reviewed-on: https://go-review.googlesource.com/c/go/+/471695 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Filippo Valsorda <filippo@golang.org> Run-TryBot: Roland Shoemaker <roland@golang.org>
Unlike the rest of nistec, the P-256 assembly doesn't use complete addition formulas, meaning that p256PointAdd[Affine]Asm won't return the correct value if the two inputs are equal. This was (undocumentedly) ignored in the scalar multiplication loops because as long as the input point is not the identity and the scalar is lower than the order of the group, the addition inputs can't be the same. As part of the math/big rewrite, we went however from always reducing the scalar to only checking its length, under the incorrect assumption that the scalar multiplication loop didn't require reduction. Added a reduction, and while at it added it in P256OrdInverse, too, to enforce a universal reduction invariant on p256OrdElement values. Note that if the input point is the infinity, the code currently still relies on undefined behavior, but that's easily tested to behave acceptably, and will be addressed in a future CL. Updates #58647 Fixes #58719 Fixes CVE-2023-24532 (Filed with the "safe APIs like complete addition formulas are good" dept.) Change-Id: I7b2c75238440e6852be2710fad66ff1fdc4e2b24 Reviewed-on: https://go-review.googlesource.com/c/go/+/471255 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org> Run-TryBot: Filippo Valsorda <filippo@golang.org> Auto-Submit: Filippo Valsorda <filippo@golang.org> Reviewed-by: Damien Neil <dneil@google.com> (cherry picked from commit 203e59a) Reviewed-on: https://go-review.googlesource.com/c/go/+/471696 Auto-Submit: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Run-TryBot: Roland Shoemaker <roland@golang.org> Reviewed-by: Filippo Valsorda <filippo@golang.org>
Unlike the rest of nistec, the P-256 assembly doesn't use complete addition formulas, meaning that p256PointAdd[Affine]Asm won't return the correct value if the two inputs are equal. This was (undocumentedly) ignored in the scalar multiplication loops because as long as the input point is not the identity and the scalar is lower than the order of the group, the addition inputs can't be the same. As part of the math/big rewrite, we went however from always reducing the scalar to only checking its length, under the incorrect assumption that the scalar multiplication loop didn't require reduction. Added a reduction, and while at it added it in P256OrdInverse, too, to enforce a universal reduction invariant on p256OrdElement values. Note that if the input point is the infinity, the code currently still relies on undefined behavior, but that's easily tested to behave acceptably, and will be addressed in a future CL. Updates golang#58647 Fixes golang#58720 Fixes CVE-2023-24532 (Filed with the "safe APIs like complete addition formulas are good" dept.) Change-Id: I7b2c75238440e6852be2710fad66ff1fdc4e2b24 Reviewed-on: https://go-review.googlesource.com/c/go/+/471255 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org> Run-TryBot: Filippo Valsorda <filippo@golang.org> Auto-Submit: Filippo Valsorda <filippo@golang.org> Reviewed-by: Damien Neil <dneil@google.com> (cherry picked from commit 203e59a) Reviewed-on: https://go-review.googlesource.com/c/go/+/471695 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Filippo Valsorda <filippo@golang.org> Run-TryBot: Roland Shoemaker <roland@golang.org>
https://groups.google.com/g/golang-announce/c/3-TpUx48iQY https://go.dev/doc/devel/release#go1.19.7 Fixes: * CVE-2023-24532 golang/go#58647 Signed-off-by: Tom Wieczorek <twieczorek@mirantis.com>
Note that the CVE fixed in go1.20.2 does *not* impact Nomad. golang/go#58647
* build: update from go1.20.1 to go1.20.2 Note that the CVE fixed in go1.20.2 does *not* impact Nomad. golang/go#58647
The assumptions of some of the assembly functions were still scarcely documented and even disregarded: p256ScalarMult was relying on the fact that the "undefined behavior" of p256PointAddAsm with regards to infinity inputs was returning the infinity. Aside from expanding comments, moving the bit window massaging into a more easily understood p256OrdRsh function, and fixing the above, this change folds the last iteration of p256ScalarMult into the loop to reduce special cases and inverts the iteration order of p256BaseMult so it matches p256ScalarMult for ease of comparison. Updates #58647 Change-Id: Ie5712ea778aadbe5adcdb478d111c2527e83caa0 Reviewed-on: https://go-review.googlesource.com/c/go/+/471256 Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org> Run-TryBot: Filippo Valsorda <filippo@golang.org> Auto-Submit: Filippo Valsorda <filippo@golang.org>
https://groups.google.com/g/golang-announce/c/3-TpUx48iQY https://go.dev/doc/devel/release#go1.19.7 Fixes: * CVE-2023-24532 golang/go#58647 Signed-off-by: Tom Wieczorek <twieczorek@mirantis.com> (cherry picked from commit f30574e)
@FiloSottile FYI https://go.dev/cl/471256 caused a minor regression in one benchmark: https://perf.golang.org/dashboard/?benchmark=GenerateKeyP256-8&unit=sec/op#commit778627f33187d874440ce1f353bb4d7bce55304a Given this is minor, part of a CVE fix, and presumably in a crypto microbenchmark, I don't think this matters much, just raising it in case you care. The benchmark is https://github.com/ethereum/go-ethereum/blob/v1.10.9/crypto/ecies/ecies_test.go#L166. |
https://groups.google.com/g/golang-announce/c/3-TpUx48iQY https://go.dev/doc/devel/release#go1.19.7 Fixes: * CVE-2023-24532 golang/go#58647 Signed-off-by: Tom Wieczorek <twieczorek@mirantis.com> (cherry picked from commit f30574e) (cherry picked from commit 38ab613)
Switch Go from the one that the OSS-Fuzz image supplies via `install_go.sh` to the latest development version cloned from Git. The OSS-Fuzz Go is an older version which still has [CVE-2023-24532](golang/go#58647) which keeps getting found by the fuzzer. Additionaly by using the latest upstream version, bugs in Go will be detected quickly after being introduced. Additionally this PR fixes the 32 bit build. The 32 bit build is currently not enabled on OSS-Fuzz because it leads to OOM bugs, but I still like to build it myself for local testing. --------- Co-authored-by: Oliver Chang <oliverchang@users.noreply.github.com>
In particular (in psuedocode)
Thanks to Guido Vranken for reporting this issue via the Ethereum Foundation bug
bounty program.
This is CVE-2023-24532 and Go issue https://go.dev/issue/58647 (this one).
The text was updated successfully, but these errors were encountered: