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!

The issue was announced here on github, and in a bunch of different places. Here’s a short Q/A to explain what’s up:

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.

Q: What’s big.Exp?

A: It’s the exponentiation function of Go. Declared in the big number library of Go: big.

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 big.Exp?

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 ;)