This is probably the cryptography bug of the year. It's easy to exploit and bypasses signature verification on anything using ECDSA in Java, including SAML and JWT (if you're using ECDSA in either).<p>The bug is simple: like a lot of number-theoretic asymmetric cryptography, the core of ECDSA is algebra on large numbers modulo some prime. Algebra in this setting works for the most part like the algebra you learned in 9th grade; in particular, zero times any algebraic expression is zero. An ECDSA signature is a pair of large numbers (r, s) (r is the x-coordinate of a randomly selected curve point based on the infamous ECDSA nonce; s is the signature proof that combines x, the hash of the message, and the secret key). The bug is that Java 15+ ECDSA accepts (0, 0).<p>For the same bug in a simpler setting, just consider finite field Diffie Hellman, where we agree on a generator G and a prime P, Alice's secret key is `a mod P` and her public key is `G^a mod P`; I do the same with B. Our shared secret is `A^b mod P` or `B^a mod P`. If Alice (or a MITM) sends 0 (or 0 mod P) in place of A, then they know what the result is regardless of anything else: it's zero. The same bug recurs in SRP (which is sort of a flavor of DH) and protocols like it (but much worse, because Alice is proving that she knows a key and has an incentive to send zero).<p>The math in ECDSA is more convoluted but not much more; the kernel of ECDSA signature verification is extracting the `r` embedded into `s` and comparing it to the presented `r`; if `r` and `s` are both zero, that comparison will always pass.<p>It is much easier to mess up asymmetric cryptography than it is to mess up most conventional symmetric cryptography, which is a reason to avoid asymmetric cryptography when you don't absolutely need it. This is a devastating bug that probably affects a lot of different stuff. Thoughts and prayers to the Java ecosystem!
This is the sort of dumb mistake that ought to get caught by unit testing. A junior, assigned the task of testing this feature, ought to see that in the cryptographic signature design these values are checked as not zero, try setting them to zero, and... watch it burn to the ground.<p>Except that, of course, people don't actually do unit testing, they're too busy.<p>Somebody is probably going to mention fuzz testing. But, if you're "too busy" to even write the unit tests for the software you're about to replace, you aren't going to fuzz test it are you?
Apparently you have to get a new CPU to fix this Java vulnerability, or alternatively a new PSU.<p>(That is to say: a <i>Critical Patch Update</i> or a <i>Patch Set Update</i>. Did they really have to overload these TLAs?)
Does anyone know why this was only given a CVSS score of 7.5? Based on the description this sounds way worse, but Oracle only gave it a CVSS Confidentiality Score of "None", which doesn't sound right. Is there some mitigating factor that hasn't been discussed?<p>In terms of OpenJDK 17 (latest LTS), the issue is patched in 17.0.3, which was release ~12h ago. Note that official OpenJDK docker images are still on 17.0.2 as of time of writing.
The fix for OpenJDK (authored on Jan. 4th 22):<p><a href="https://github.com/openjdk/jdk/blob/e2f8ce9c3ff4518e070960bafa70ba780746aa5c/src/jdk.crypto.ec/share/classes/sun/security/ec/ECDSAOperations.java#L225" rel="nofollow">https://github.com/openjdk/jdk/blob/e2f8ce9c3ff4518e070960ba...</a>
What puzzles me most is that two days after the announcement of the vulnerability and the release of the patched Oracle JDK, there is still no patched version of OpenJDK for most distributions.<p>We're running some production services on OpenJDK and CentOS and until now there are only two options to be safe: shutdown the services or change the crypto provider to BouncyCastle or something else.<p>The official OpenJDK project lists the planned release date of 17.0.3 as April 19th, still the latest available GA release is 17.0.2 (<a href="https://wiki.openjdk.java.net/display/JDKUpdates/JDK+17u" rel="nofollow">https://wiki.openjdk.java.net/display/JDKUpdates/JDK+17u</a>).<p>Adoptium have a large banner on their website and until now there is not a single patched release of OpenJDK available from them (<a href="https://github.com/adoptium/adoptium/issues/140" rel="nofollow">https://github.com/adoptium/adoptium/issues/140</a>).<p>There are no patched packages for CentOS, Debian or openSUSE.<p>The only available version of OpenJDK 17.0.3 I've seen until now seems to be the Archlinux package (<a href="https://archlinux.org/packages/extra/x86_64/jdk17-openjdk/" rel="nofollow">https://archlinux.org/packages/extra/x86_64/jdk17-openjdk/</a>). They obviously have their own build.<p>How can it be that this is not more of an issue? I honestly don't get how the release process of something as widely used as OpenJDK can take more than 2 days to provide binary packages for something already fixed in the code.<p>This shouldn't be much more effort than letting the CI do its job.<p>Edit: Typo.
>Just a basic cryptographic risk management principle that cryptography people get mad at me for saying (because it’s true) is: don’t use asymmetric cryptography unless you absolutely need it.<p>Is there any truth to this? Doesn't basically all Internet traffic rely on the security of (correctly implemented) asymmetric cryptography?
Wonder if someone can add a little more info to the title of this story. It's would probably draw more clicks if the title wasn't so cryptic. This is essentially a Java dev infosec post.
It's crazy that the check for this was right there in the original code and was obviously missed when porting to Java. Great example of why unit tests are part of the code (and were missing in both in this case).
Q: Which type of cryptography is implied to be unsafe in the following sentence?:<p>"Immediately ditch RSA in favor of EC, for it is too hard to implement safely!"
Computerphile has released a very approachable explanation of the flaw[1], along with some basic background on ECDSA as well.<p>[1]: <a href="https://www.youtube.com/watch?v=502iGDxuiRk" rel="nofollow">https://www.youtube.com/watch?v=502iGDxuiRk</a>
And once again, you'd be saved if you stayed on an older release. This is the third time this has happened recently in the Java world: the Spring4Shell vulnerability only applies to Java 9 and later (that vulnerability depends on the existence of a method introduced by Java 9, since all older methods were properly blacklisted by Spring), and the Log4Shell vulnerability only applies to log4j 2.x (so if you stayed with log4j 1.x, and didn't explicitly configure it to use a vulnerable appender, you were safe). What's going on with Java?