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

math/big: panic during recursive division of very large numbers #42552

Closed
katiehockman opened this issue Nov 12, 2020 · 4 comments
Closed

math/big: panic during recursive division of very large numbers #42552

katiehockman opened this issue Nov 12, 2020 · 4 comments
Labels
Milestone

Comments

@katiehockman
Copy link
Member

@katiehockman katiehockman commented Nov 12, 2020

A number of math/big.Int methods (Div, Exp, DivMod, Quo, Rem, QuoRem, Mod, ModInverse, ModSqrt, Jacobi, and GCD) can panic when provided crafted large inputs. For the panic to happen, the divisor or modulo argument must be larger than 3168 bits (on 32-bit architectures) or 6336 bits (on 64-bit architectures). Multiple math/big.Rat methods are similarly affected.

crypto/rsa.VerifyPSS, crypto/rsa.VerifyPKCS1v15, and crypto/dsa.Verify may panic when provided crafted public keys and signatures. crypto/ecdsa and crypto/elliptic operations may only be affected if custom CurveParams with unusually large field sizes (several times larger than the largest supported curve, P-521) are in use. Using crypto/x509.Verify on a crafted X.509 certificate chain can lead to a panic, even if the certificates don’t chain to a trusted root. The chain can be delivered via a crypto/tls connection to a client, or to a server that accepts and verifies client certificates. net/http clients can be made to crash by an HTTPS server, while net/http servers that accept client certificates will recover the panic and are unaffected.

Moreover, an application might crash invoking crypto/x509.(*CertificateRequest).CheckSignature on an X.509 certificate request or during a golang.org/x/crypto/otr conversation. Parsing a golang.org/x/crypto/openpgp Entity or verifying a signature may crash. Finally, a golang.org/x/crypto/ssh client can panic due to a malformed host key, while a server could panic if either PublicKeyCallback accepts a malformed public key, or if IsUserAuthority accepts a certificate with a malformed public key.

Thanks to the Go Ethereum team and the OSS-Fuzz project for reporting this. Thanks to Rémy Oudompheng and Robert Griesemer for their help developing and validating the fix.

This issue is CVE-2020-28362.

@katiehockman
Copy link
Member Author

@katiehockman katiehockman commented Nov 12, 2020

Fixed by 1e1fa59

@aaronbee
Copy link

@aaronbee aaronbee commented Nov 17, 2020

Is go1.13 affected? I noticed that the fix touches code that was added in commit 194ae32 which is not present in go1.13.

@cristaloleg
Copy link

@cristaloleg cristaloleg commented Nov 17, 2020

Looks like 1.13 isn't supported anymore, only 1.14 and 1.15 for today https://golang.org/doc/devel/release.html#policy

@aaronbee
Copy link

@aaronbee aaronbee commented Nov 17, 2020

I understand that. I'm just asking if someone knows if go1.13 is affected. It is useful to know if programs built with go1.13 currently out in the wild are susceptible. I can check myself when the test is published, but I was hoping to get an earlier answer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.