Major cryptographic mistake in Java allows forging “spiritual paper”

Organizations using a newer version of Oracle’s Java framework woke up Wednesday to ill-advised advice: A critical vulnerability could make it easy for adversaries to forge TLS certificates and signatures. Two-factor authentication and authorization credentials are generated by a series of widely used standards.

Security hole Oracle patched on Tuesdayaffect the company’s performance Elliptic curve digital signature algorithm in Java version 15 and above. ECDSA is an algorithm that uses the principles of elliptic curve cryptography to authenticate digital messages. A key advantage of ECDSA is the smaller size of the keys it generates, compared to RSA or other cryptographic algorithms, making it ideal for use in standards including 2FA based on FIDOthe Security validation markup language, OpenIDand JSON.

Which doctor? and spiritual paper

Neil Madden, researcher at security firm ForgeRock, who Vulnerability discoveredare likened to blank identification cards that frequently appear in science fiction shows Which doctor?. The spiritual paper cards are created to make the person looking at it can see whatever the main character wants them to see.

“It turns out that some recent releases of Java are vulnerable to a similar kind of trick, in the implementation of ECDSA Madden wrote. “If you are running one of the vulnerable versions, an attacker can easily forge some sort of SSL certificate and shake hands (allowing interception and modification of communications), JWT signed, Confirm SAML or OIDC . id tokenand even WebAuthn authentication message. All use the digital equivalent of a blank sheet of paper. ”

He continued:

“It is difficult to overstate the severity of this bug. If you are using ECDSA signatures for any of these security mechanisms, an attacker could trivially and completely ignore them if your server is running any previous version of Java 15, 16, 17 or 18 April 2022 Critical Patch Update (CPU). For context, almost all real-world WebAuthn/FIDO devices (including Yubikeys use ECDSA signatures, and many OIDC providers use ECDSA signed JWTs.”

The bug, tracked as CVE-2022-21449, carries a severity rating of 7.5 out of 10 possibilities, but Madden said based on his assessment he would rate severity at perfect 10 “due to the various functional impacts in the context of access management.” In its ugliest form, the bug can be exploited by someone outside the vulnerable network without any verification.

Other security experts also had strong reactions, with a declare it “Crypto Bug of the Year.”

One mitigating factor is that Java versions 15 and above do not appear to be as widely used as earlier versions. Data collected in February and March 2021 from security firm Snyk shows that Java 15, the latest version at the time, accounted for 12% of deployments. While Madden says that the specific ECDSA implementation vulnerability only affects Java 15 and later, Oracle also lists versions 7, 8, and 11 as vulnerable. Madden said that the discrepancy could be due to separate cryptographic bugs that were fixed in previous releases.

a / 0 = valid signature

The ECDSA signature is based on a pseudo-random number, usually denoted K, that is used to derive two complement numbers, R and S. To verify the signature is valid, one party must check the association equation. involves R and S, the signer’s public key, and a cryptographic hash of the message. When both sides of the equation are equal, the signature is valid.

In one The manuscript was published on WednesdaySecurity firm Sophos further explains the process:

S1. Choose a random cipher sound integer K from 1 to N-1.
S2. Calculate R from K using Elliptic Curve multiplication.
S3. In the unlikely event that R is 0, go back to step 1 and start over.
S4. Calculate S from K, R, signed hash and private key.
S5. In case S is 0, go back to step 1 and start over.

For the process to work correctly, neither R nor S can be zero. That’s because one side of the equation is R and the other side is multiplied by R and one value from S. If both values ​​are 0, the verification test turns to 0 = 0 X (other values ​​from private key and hash), which will be true regardless of the additional values. That means the adversary only needs to submit a blank signature to successfully pass the verification check.

Madden wrote:

Guess the check that Java forgot?

That’s right. Java’s implementation of ECDSA signature verification doesn’t check if R or S is zero, so you can generate a signature value that is both zero (properly encoded) and Java will accept it as a valid signature for any notice and for any public. Key. The digital equivalent of a blank ID card.

Here’s an interactive JShell session Madden created showing a vulnerable implementation that accepts an empty signature as valid when verifying messages and public keys:

|  Welcome to JShell -- Version 17.0.1
|  For an introduction type: /help intro
jshell> import java.security.*
jshell> var keys = KeyPairGenerator.getInstance("EC").generateKeyPair()
keys ==> java.security.KeyPair@626b2d4a
jshell> var blankSignature = new byte[64]
blankSignature ==> byte[64] { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, ... , 0, 0, 0, 0, 0, 0, 0, 0 }
jshell> var sig = Signature.getInstance("SHA256WithECDSAInP1363Format")
sig ==> Signature object: SHA256WithECDSAInP1363Format<not initialized>
jshell> sig.initVerify(keys.getPublic())
jshell> sig.update("Hello, World".getBytes())
jshell> sig.verify(blankSignature)
$8 ==> true
// Oops, that shouldn't have verified...

Organizations that are using any of the affected versions of Java for signature validation should place a high priority on patching. It’s important to follow advice from app and product manufacturers to see if any of their products are vulnerable. Although the threat from CVE-2022-21449 appears to be limited to new versions of Java, its severity is high enough to warrant vigilance.