posted April 2016
CVE-2016-3959 also called the golang infinite loop just triggered a new version of the language Go. The cherry on the cake is that it was discovered by me!
Q: What's vulnerable?
A: Anything that uses the
big.Exp function concurrently where the modulo parameter can be controlled by an attacker. For crypto this means mostly DSA and RSA which are used for example in TLS and SSH, as well as many other cryptographic applications, like recently in the Let's Encrypt client (hope they patched). ECDSA also use the
big.Exp function but this elliptic curve version of DSA usually does not use custom curves so the attacker has usually no known way to make someone compute calculations over his curves parameters if they are non-standard.
func (z *Int) Exp(x, y, m *Int) *Int
Q: What's a big number library?
A: Programming languages have
int types that can usually hold integers up to 64bits (For example, in C this type is called
uint64_t). But crypto needs numbers that are much bigger than that, up to 4000 bits sometimes. So big number libraries are the libraries used to play with numbers of such sizes without getting a headache =)
Q: What was the problem with
A: It was a pretty simple one, the lack of a zero check for the modulus made the calculation turn into an infinite loop. Interestingly the developers of Go did not patch the vulnerability by adding the zero check inside of
big.Exp but did it inside of the implementations of DSA, RSA and ECDSA. This means that other cryptographic functions or non-cryptographic functions that employ this
big.Exp function, concurrently, with the third parameter controlled by the user, might still be subject to DoS attacks.
If you have any other questions feel free to ask! The comment section is here for that ;)