CVE-2022-21449 “Psychic Signatures”: Analyzing the New Java Crypto Vulnerability
A few days ago, security researcher Neil Madden published a blog post, in which he provided details about a newly disclosed vulnerability in Java, CVE-2022-21449 or “Psychic Signatures”. This security vulnerability originates in an improper implementation of the ECDSA signature verification algorithm, introduced in Java 15.
This vulnerability allows an attacker to potentially intercept communication and messages that should have otherwise been encrypted, such as SSL communication, authentication processes (like JWT), and more.
In this blogpost we provide details on the vulnerability, what are the applicability conditions of it, and how to remediate it.
What is CVE-2022-21449?
CVE-2022-21449 is a vulnerability in the implementation of the Elliptic Curve Digital Signature Algorithm, caused by an improper implementation of the signature verification algorithm. Effectively, it causes the nullification of content’s integrity, which is guaranteed by signatures. This may be SSL handshakes, signatures, certificates, etc., should they be using ECDSA.
The signature validation algorithm uses a mathematical equation that consists of the signer’s public key, a hash of the message, and two values that are used in ECDSA signatures, r and s. A signature is validated when both sides of the equation are equal.
The faulty implementation introduced in Java 15 doesn’t check that the r and s values in use are not 0, and this is where trouble starts. If r and s are allowed to be zero, this may cause both sides of the equation that uses them for multiplication to be zeroed, thus creating a true statement 0 = 0. In this case the signature will be validated, allowing an attacker with an empty signature (full of zeroes) to access content that should be protected.
Who is affected by CVE-2022-21449?
CVE-2022-21449 affects Java versions 15, 16, 17 and 18, according to the original publication. Oracle initially released a statement about patching versions 7, 8 and 11 as well, implying that those versions were also vulnerable, however they have since revised that statement to include only Java 15+ as affected. It can be seen that versions older than 15 are not vulnerable to this exact same issue by running the original exploit:
Note the false verification result, indicating the vulnerability was not exploited successfully.
Java applications that are vulnerable are those who use any variation of the ECDSA algorithm with Java’s getInstance() signature API. For example:
Signature.getInstance("SHA256WithECDSAInP1363Format")JFrog Xray can validate or rule out the applicability of this CVE in your code with our Contextual Analysis feature, which performs code analysis on a scanned project, and is able to detect such vulnerable calls to getInstance() with the usage of ECDSA algorithm and report the applicability of the vulnerability accordingly:
"CVE-2022-21449": CodeScanner(
ScannerType.JAR,
GadgetFactoid(
Pipe(
Callsites("java/security/Signature", "getInstance"),
CallArgumentMatcherRegex({1: ".*withECDSA.*"})
),
"Java ECDSA signature is {not }used",
),
[b"withECDSA"],
),We advise you to use our OSS tool to determine whether your applications are vulnerable to CVE-2022-21449.
Get the OSS ToolIs the JFrog platform vulnerable to CVE-2022-21449?
After conducting a comprehensive internal inspection, we concluded that JFrog DevOps platform is not vulnerable to CVE-2022-21449.
What is the impact of CVE-2022-21449?
An attacker exploiting this vulnerability may be able to intercept (read and alter) encrypted communications, or bypass authentication in some cases. Moreover, in cases where content integrity is validated using ECDSA signatures, the validation process may be compromised.
How can you remediate CVE-2022-21449?
To remediate this Java vulnerability, we recommend upgrading Java to the latest version for each branch: 17.03 or 18.0.1.
Book a demo of Xray security tool!
Book a Demo
What mitigation options are available for
CVE-2022-21449?
In case upgrading Java is impossible, we recommend using another signature algorithm. This is the list of ECDSA variations that should not be used:
NONEwithECDSA SHA1withECDSA SHA224withECDSA SHA256withECDSA SHA384withECDSA SHA512withECDSA SHA3-224withECDSA SHA3-256withECDSA SHA3-384withECDSA SHA3-512withECDSA NONEwithECDSAinP1363Format SHA1withECDSAinP1363Format SHA224withECDSAinP1363Format SHA256withECDSAinP1363Format SHA384withECDSAinP1363Format SHA512withECDSAinP1363Format SHA3-224withECDSAinP1363Format SHA3-256withECDSAinP1363Format SHA3-384withECDSAinP1363Format SHA3-512withECDSAinP1363Format
Instead, we recommend using the EdDSA or Ed25519 signature algorithms. If legacy support is needed – any other variation of the RSA or DSA algorithms can be used. See the Java documentation for a list of the supported algorithms.
Stay up-to-date with JFrog Security Research
Follow the latest discoveries and technical updates from the JFrog Security Research team in our security research blog posts and on Twitter at @JFrogSecurity.
Find vulnerable versions with JFrog Xray
In addition to exposing new security vulnerabilities and threats, JFrog provides developers and security teams easy access to the latest relevant information for their software with automated security scanning by JFrog Xray SCA tool.
