What the ECDSA Flaw in Java Means for Enterprises

Oracle has patched a critical vulnerability in newer versions of Java that adversaries could exploit to forge security certificates, digital signatures, two-factor authentication messages, and authorization credentials. The security fix was included in the April 2022 Critical Patch Update released last week.

The issue (CVE-2022-21449) exists in the way the Elliptic Curve Digital Signature Algorithm (ECDSA) is implemented in Java versions 15, 16, 17, and 18. Defenders should check what version of Java they are running and update. Java 15 and 16 are no longer supported, and the issue has been fixed in Java 17.0.3 and 18.0.1.

1. Check and update: Check what version of Java is running with the command java -version (or java.exe -version on Windows).

It’s worth checking manually because it’s possible to have multiple Java versions installed on the system simultaneously, since there could be different versions of the Java Development Kit (JDK) and Java Runtime Environment (JRE).

For many organizations, the fact that the vulnerability exists in only the latest versions may be good news, since the adoption for Java 15 and newer remains fairly low.

2. Pay attention to advisories: Java is widely used, so enterprise teams will need to keep an eye out for advisories from app and device manufacturers on whether they are affected and update as needed. The vulnerability doesn’t just affect Internet-accessible Java servers and client software – any device that relies on digitally signed data is potentially affected, even if it is an internal device.

Details of the Flaw
ECDSA uses elliptic curve cryptography to authenticate messages. A missing sanity check in ECDSA means that adversaries can pass the signature check by presenting a memory buffer filled entirely with zeros. This means adversaries can easily forge TLS certificates and handshakes, which would result in communications being intercepted and potentially modified, wrote Neil Madden, the ForgeRock researcher who discovered the vulnerability. There is no need for an attacker to try to figure out the private key in order to match the valid digital signature.

The vulnerability affects “almost all WebAuthn/FIDO devices in the real world,” Madden wrote. “Many OIDC providers also use ECDSA-signed JWTs.”

Limited to Newer Versions
Back in November, when Madden reported the flaw to Oracle, ForgeRock provided customers with two workarounds – to deploy products with Java 11 or to configure the Java Virtual Machine to use Bouncy Castle as the preferred cryptographic provider.

The fact that the vulnerability is present only in the newer versions may mean the impact of this flaw may be blunted, as adoption rates for Java 15 and newer remain fairly low. The fifth Developer Ecosystem Survey, released in July 2021, found that just 14% of developers were using Java 15 (the most recent version at the time of the survey). The most widely used version is Java 8 (72%), followed by Java 11 (42%). Java 11 was the long-term-support version.

Even though Oracle assigned a severity rating of 7.5 out of 10, Madden said the severity should be a 10, “due to the wide range of impacts on different functionality in an access management context.” There are claims of the flaw being the “crypto bug of the year.”

Editor’s Note: This piece was updated to remove the reference that some Yubikeys may be affected. Yubico sent the following statement to Dark Reading:

“Yubico is aware of this issue and how it affects Oracle Java 15+ and OpenJDK, including other JDKs derived from OpenJDK. This vulnerability is not in the YubiKey firmware or the WebAuthn protocol, and we recommend organizations and individuals patch their Java deployments. Yubico will continue to provide further guidance on best practices as appropriate in the future.”