OpenJDK のセキュリティ・アップデート（2022-04）

CVE ID	Component	CVSSv3.1 Score	Affects ...
			7	8	11	13	15	17	18
CVE-2022-21476	security-libs/java.security	7.5
CVE-2022-21449	security-libs/java.security	7.5
CVE-2022-21496	core-libs/javax.naming	5.3
CVE-2022-21434	core-libs/java.lang	5.3
CVE-2022-21426	xml/jaxp	5.3
CVE-2022-21443	security-libs/java.security	3.7

The vulnerability, which Oracle patched on Tuesday, affects the company’s implementation of the Elliptic Curve Digital Signature Algorithm in Java versions 15 and above. ECDSA is an algorithm that uses the principles of elliptic curve cryptography to authenticate messages digitally. A key advantage of ECDSA is the smaller size of the keys it generates, compared to RSA or other crypto algorithms, making it ideal for use in standards including FIDO-based 2FA, the Security Assertion Markup Language, OpenID, and JSON.

ECDSA signatures rely on a pseudo-random number, typically notated as K, that’s used to derive two additional numbers, R and S. To verify a signature as valid, a party must check the equation involving 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.

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

Guess which check Java forgot?

That’s right. Java’s implementation of ECDSA signature verification didn’t check if R or S were zero, so you could produce a signature value in which they are both 0 (appropriately encoded) and Java would accept it as a valid signature for any message and for any public key. The digital equivalent of a blank ID card.