david wong

Hey! I'm David, cofounder of zkSecurity and the author of the Real-World Cryptography book. I was previously a crypto architect at O(1) Labs (working on the Mina cryptocurrency), before that I was the security lead for Diem (formerly Libra) at Novi (Facebook), and a security consultant for the Cryptography Services of NCC Group. This is my blog about cryptography and security and other related topics that I find interesting.

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

golang infinite rainbow loop

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

Well done! You've reached the end of my post. Now you can leave a comment or read something else.

Comments

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

leave a comment...