Skip to content
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: CPU DoS vulnerability affecting P-521 and P-384 #29903

Closed
julieqiu opened this issue Jan 23, 2019 · 8 comments
Closed

crypto/elliptic: CPU DoS vulnerability affecting P-521 and P-384 #29903

julieqiu opened this issue Jan 23, 2019 · 8 comments

Comments

@julieqiu
Copy link
Member

julieqiu commented Jan 23, 2019

A DoS vulnerability in the crypto/elliptic implementations of the P-521 and P-384 elliptic curves may let an attacker craft inputs that consume excessive amounts of CPU.

These inputs might be delivered via TLS handshakes, X.509 certificates, JWT tokens, ECDH shares or ECDSA signatures. In some cases, if an ECDH private key is reused more than once, the attack can also lead to key recovery.

This issue is CVE-2019-6486. It was found and reported by the Wycheproof project.

@gopherbot
Copy link

Change https://golang.org/cl/159218 mentions this issue: crypto/elliptic: reduce subtraction term to prevent long busy loop

@mirtchovski
Copy link
Contributor

Can you elaborate on this, thank you:

"if an ECDH private key is reused more than once, the attack can also lead to key recovery."

@FiloSottile
Copy link
Contributor

FiloSottile commented Jan 24, 2019

Can you elaborate on this, thank you:

"if an ECDH private key is reused more than once, the attack can also lead to key recovery."

If ECDH is used in an Ephemeral-Static protocol, the attacker can use multiple tries to recover the static private key. crypto/tls does not reuse ECDH private keys, so is unaffected, but certain JWT encryption modes are based on ECDH-ES, so would be affected if the private key is a P-384 or P-521 key.

@pawanrawal
Copy link

pawanrawal commented Jan 24, 2019

Was this issue introduced with go v1.10? Should we be updating projects using versions below v1.10?

kopano-bot pushed a commit to Kopano-dev/libkcoidc that referenced this issue Jan 24, 2019
gentoo-bot pushed a commit to gentoo/gentoo that referenced this issue Jan 24, 2019
This is going directly to stable on amd64.
Bug: golang/go#29903
Copyright: Sony Interactive Entertainment Inc.
Package-Manager: Portage-2.3.56, Repoman-2.3.12
RepoMan-Options: --force

Signed-off-by: William Hubbs <williamh@gentoo.org>
clrpackages pushed a commit to clearlinux-pkgs/go that referenced this issue Jan 24, 2019
Resolves CVE-2019-6486. See details at
golang/go#29903.

Signed-off-by: Patrick McCarty <patrick.mccarty@intel.com>
@FiloSottile
Copy link
Contributor

Was this issue introduced with go v1.10? Should we be updating projects using versions below v1.10?

No, this was introduced earlier, but we only support the last two Go releases.

@remyoudompheng
Copy link
Contributor

Out of curiosity, why didn't we remove this "Add(P)" altogether ? Mod(P) is always called afterwards and the specification of big.Int.Mod says it will never return a negative number if P > 0.

@FiloSottile
Copy link
Contributor

@remyoudompheng Security patches aim to be as minimal as possible. A follow-up change will indeed significantly simplify that function.

mvladev pushed a commit to mvladev/gardener that referenced this issue Jan 25, 2019
mvladev pushed a commit to gardener-attic/gardener-extensions that referenced this issue Jan 25, 2019
**What this PR does / why we need it**:

> We have just released Go 1.11.5 and Go 1.10.8 to address a recently reported security issue. We recommend that all users update to one of these releases (if you’re not sure which, choose Go 1.11.5).
>
> This DoS vulnerability in the crypto/elliptic implementations of the P-521 and P-384 elliptic curves may let an attacker craft inputs that consume excessive amounts of CPU.
>
> These inputs might be delivered via TLS handshakes, X.509 certificates, JWT tokens, ECDH shares or ECDSA signatures. In some cases, if an ECDH private key is reused more than once, the attack can also lead to key recovery.
>
> The issue is CVE-2019-6486 and Go issue golang/go#29903. See the Go issue for more details.

K8S issue kubernetes/kubernetes#73238

**Which issue(s) this PR fixes**:
n/a

**Special notes for your reviewer**:

**Release note**:
<!--  Write your release note:
1. Enter your release note in the below block.
2. If no release note is required, just write "NONE" within the block.

Format of block header: <category> <target_group>
Possible values:
- category:       improvement|noteworthy|action
- target_group:   user|operator
-->
```improvement operator
NONE
```

/cc @ThormaehlenFred
russjones pushed a commit to gravitational/go that referenced this issue Jan 28, 2019
If beta8 is unusually large, the addition loop might take a very long
time to bring x3-beta8 back positive.

This would lead to a DoS vulnerability in the implementation of the
P-521 and P-384 elliptic curves that may let an attacker craft inputs
to ScalarMult that consume excessive amounts of CPU.

This fixes CVE-2019-6486.

Fixes golang#29903

Change-Id: Ia969e8b5bf5ac4071a00722de9d5e4d856d8071a
Reviewed-on: https://team-review.git.corp.google.com/c/399777
Reviewed-by: Adam Langley <agl@google.com>
Reviewed-by: Julie Qiu <julieqiu@google.com>
Reviewed-on: https://go-review.googlesource.com/c/159218
Reviewed-by: Julie Qiu <julie@golang.org>
Mic92 pushed a commit to NixOS/nixpkgs that referenced this issue Jan 29, 2019
Upstream only supports two latest releases.
golang/go#29903 (comment)

(cherry picked from commit a687ef9)
@FiloSottile
Copy link
Contributor

This was not mentioned in the announcement by my mistake, but this issue was found by running Wycheproof test vectors, and reported by the Wycheproof team.

richardyuwen pushed a commit to richardyuwen/gardener that referenced this issue Mar 26, 2019
@golang golang locked and limited conversation to collaborators Mar 13, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants