# CVE-2016-3959 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!

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

## <script>alert(0);</script>

<script>alert(2);</script>

<b>lol</b>

## asdf

test again

## david

really :| ?

## jc

Je pense que t'as une faille David, le script en lien sur le 1er com s’exécute si on clique dessus

http://security.stackexchange.com/questions/11985/will-javascript-be-executed-which-is-in-an-href

## sagi

Congrats :)