Java versions 15 through 18 contain a flaw in its ECDSA signature validation that makes it trivial for criminals to digitally sign files and other data as if they were legitimate organizations.

Cybercriminals could therefore pass off cryptographically signed malicious downloads and false information as if it were real, and the affected Java applications and services will not know the difference.

The scope of damage that could be done is vast: encrypted communications, authentication tokens, code updates, etc., built on faulty Oracle code could be reversed, and as far as Vulnerable programs written in Java, data appear legitimate and reliable.

The gaffe was patched this month by Oracle – among more than 500 vulnerabilities patched by the database giant this quarter – so, as always, update early and update often.

ECDSA stands for Elliptic Curve Digital Signature Algorithm. It uses elliptic curve cryptography, implementations of which have encountered various problems over the years.

Although Oracle only gave this latest security flaw (CVE-2022-21449) a severity rating of 7.5 out of 10, security consultancy ForgeRock – which said it had seen it and disclosed it privately in November – rates the vulnerability out of ten.

Infosec expert Thomas Ptacek once described it as “the crypto bug of the year”, which we’re inclined to agree with.

Good. This is the crypto bug of the year. Write it down for April. Java 15-18 ECDSA does not check that the random x coordinate and signature proof are not null; a signature (0,0) validates any message. Case JWT, SAML, etc. https://t.co/t2WgnS0g3A

—Thomas H. Ptacek (@tqbf) April 20, 2022

What’s particularly interesting about this problem is that it’s incredibly easy to exploit, and it’s an obvious programming error. The bug was introduced when some of Java 15’s signature verification code was rewritten from its native C++ to Java itself – including the ECDSA verification code.

To simplify what happened, an ECDSA signature consists of a pair of numbers, called (r, s). To verify a signature, the code performs calculations involving a hash (a fingerprint, if you will) of the data, the public key of the organization or person who digitally signed the data, rand s; one side of the equation uses rThe other r and s.

Both sides of this calculation must be equal for signature verification to pass. This would mean that the data has been digitally signed by the signer’s private key, indicating that the data comes from or is trusted by the signer. If the signature verification fails, it probably means that the person who signed the data is not who they claim to be (because they don’t have access to the secret private key that matches the given public key) and that the data should not be trusted.

In theory, for a signature to be valid, (r, s) it’s not possible (0, 0) because some calculations involve multiplying these numbers by other values. The bug arose because the original C++ code checked that both r and s are nonzero and would not accept the signature if they were. The new Java code didn’t check, it just went forward and calculated with the values.

You don’t need to know a lot of math to know that anything multiplied by zero equals zero. Part of the calculation is to divide by s – but, unfortunately, in a way that doesn’t generate an error if you divide by zero.

The result is that in the affected versions of the code, anyone with a blank signature will be accepted. The normal audit trail still works fine, which is why it wasn’t noticed two years ago. He just accepts now (0,0)and validate it successfully.

And that’s on top of gazillon’s remote code execution flaws, with no authentication needed to exploit, in Oracle’s other products. ®

Boot Note

This defect was describe by Neil Madden of ForgeRock as psychic paper vulnerability, after a plot device from a 2007 Doctor Who episode. Your humble book vulture thinks this sounds more like the imp card from AA Attanasio’s 1987 novel In Other Worlds:

You will receive a third and final artifact, a magnetic interface plate – an imp. It looks like a cash card, except it’s pure white. Insert it into any banking computer system and you will be credited with large sums of real capital.