Oracle pushed out a security update yesterday to fix a vulnerability that allowed attackers to forge certain types of SSL certificates and handshakes, two-factor authentication information, and authorization credentials generated by a range of widely used open standards. This allows an attacker to easily digitally sign files and other data.
This vulnerability affects the implementation of ECDSA (Elliptic Curve Digital Signature Algorithm) in Java 15 and above. ECDSA is an algorithm that uses elliptic curve cryptography principles to digitally authenticate messages. A key advantage of ECDSA over RSA or other cryptographic algorithms is that it generates smaller keys, making it ideal for use in standards including FIDO-based 2FA, SMAL, and OpenID.
The CVE ID for this vulnerability is CVE-2022-21449 and was originally discovered by ForgeRock security researcher Neil Madden, who wrote about it in Vulnerability Description writes that
If you use ECDSA signatures in these security mechanisms, and if your server is running any Java version 15, 16, 17, or 18 before the April 2022 Critical Patch Update (CPU), an attacker can easily bypass them altogether. Almost all WebAuthn/FIDO devices today (including Yubikeys) use ECDSA signatures, and many OIDC providers are also using ECDSA-signed JWTs.
Madden notes that these affected Java versions are primarily due to their failure to check two key variables in ECDSA to ensure that they are non-zero.
The ECDSA signature relies on a pseudo-random number, usually denoted K, to derive two additional numbers, R and S. To verify that the signature is valid, the equation involving R and S must be checked. A signature is valid when both sides of the equation are equal. In order for the process to work properly, neither R nor S can be zero.
This is because if the values are both zero, both sides of the equation will always be equal, and the signature will always be valid. This means that only a blank signature needs to be submitted to successfully pass the validation check.
This bug was introduced when the code in question was rewritten from C++ to Java, and the vulnerability dates back as far as the release of Java 15 in 2020. The bug was discovered and reported to Oracle last November, and Oracle fixed the issue in the April Critical Patch Update (CPU) that was rolled out.
Oracle rated the vulnerability as a 7.5 out of 10 for severity in the Common Vulnerability Scoring System, but Madden rated the vulnerability as a 10 for severity based on his own assessment. In addition to Madden’s assessment that the vulnerability is very serious, another security expert, Thomas Ptacek, named the vulnerability Crypto bug of the year.
Java 15 and above is not as widely used by developers as earlier versions of Java. Data from security firm Snyk in 2021 showed that Java 15 had only a 12% share at that time.