How To Fix CVE-2022-21449- Psychic Signatures Vulnerability In Java

A Security researcher from ForgeRock, Neil Madden disclosed and reported a vulnerability in the Cryptographic function in Java. The vulnerability is assigned a CVE ID CVE-2022-21449 with a CVSS score of 7.5, which is High in severity and is a digital signature bypass vulnerability in Java. The flaw is dubbed Psychic Signatures vulnerability, which allows attackers to easily forge some types of SSL certificates and TLS handshakes in a secured communication. This enables attackers to bypass signed JWTs, SAML assertions or OIDC id tokens, and even WebAuthn authentication messages and intercept or even tamper with the communication on a secured encrypted channel. So it is highly important to fix the Psychic Signatures Vulnerability in Java. We urge everybody to learn how to fix CVE-2022-21449, Psychic Signatures Vulnerability, in your Java application. And, don’t forget to contact all your third-party application Vendors to fix this issue.

Let’s Learn About ECDSA Signatures:

It is important to The Elliptic Curve Digital Signature Algorithm (ECDSA) is a digital signature algorithm used to sign electronic documents. It is based on the elliptic curve cryptography (ECC) algorithm, which is used to generate public and private keys. ECDSA signatures are considered more secure than traditional RSA signatures, and they are also shorter and faster to generate. This made ECDSA prevalent in a place where speed and size is a deciding factors. Today, ECDSA emerged as a global standard for a wide range of signature algorithms except for a few algorithms like Windows Hello, which uses the RSA algorithm for older TPM comparability issues.

To tell in simple words, the ECDSA signature is made up of two values called r and s. To verify an ECDSA signature, the verifier compares a formula with r, s, the signer’s public key, and the message’s hash. The signature is valid if both sides of the equation are equal, otherwise, it is considered invalid and will be rejected. So it is much important that both r and s shouldn’t be ‘0’ to validate the signature. It is the first check to verify the values of r and s. The ECDSA signature verification process should ensure that values of r and s are both >= 1.

How Does Psychic Signatures Vulnerability Work In Java?

Java’s implementation of the ECDSA signature verification process is unable to verify if r or s is ‘0’. Due to this verification failure, Java will accept the signature as a valid signature even if r and s are ‘0’. This allows anybody to produce a signature with r and s ‘0’. Java will consider it as a valid signature for any message and for any public key. This makes a blank ID card will be accepted as a valid ID card.

Here is the vulnerable implementation code of the interactive jshell session accepting a blank signature as a valid signature for an arbitrary message and public key:

|  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 ==> [email protected] 
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...

Summary of CVE-2022-21449

Psychic Signatures Vulnerability is a digital signature bypass vulnerability in Java that is due to poor implementation of the Elliptic Curve Digital Signature Algorithm in Java. This signature bypass vulnerability makes Java accept a blank signature as a valid signature. Attackers could abuse this Psychic Signatures vulnerability to bypass signed JWTs, SAML assertions or OIDC id tokens, and even WebAuthn authentication messages and intercept or even tamper with the communication on a secured encrypted channel.

The flaw is rated High in severity with a CVSS score of 7.5, considering no impact on Confidentiality or Availability. However, Neil Madden, a security researcher from ForgeRock, says that “It’s hard to overstate the severity of this bug” due to the wide range of impacts on different functionality in an Identity and Access Management (IAM) context and assigned a CVSS score of 10.0.

Java Versions Affected by Psychic Signatures Vulnerability

As per the OpenJDK advisory, the flaw CVE-2022-21449 impacts OpenJDK versions 15, 17, and 18. However, Oracle says that this flaw affects these versions of Oracle Java SE and Oracle GraalVM Enterprise Edition:

• Oracle Java SE: 7u331, 8u321, 11.0.14, 17.0.2, 18
• Oracle GraalVM Enterprise Edition: 20.3.5, 21.3.1, 22.0.0.2

To your note, This vulnerability also affects Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets that load and run untrusted code and rely on the Java sandbox for security. This flaw can be exploited by any application or service which is running Java 15, 16, 17, or 18. This would cover almost all WebAuthn/FIDO servers in the real world that use ECDSA signatures.

Psychic Signatures Vulnerability PoC

Khaled Nassar, a security researcher, has published a Proof-of-Concept to demonstrate Psychic Signatures Vulnerability in Java. In this PoC, the researcher used a vulnerable client and a malicious TLS server.

In this demonstration, the researcher installed a valid SSL certificate chain for www.google.com with an ECDSA pub key on the malicious server. On the other hand, he modified the crypto/ecdsa package to provide an improper signature with r = s = 0. Then the researcher showed how the vulnerable client validates this invalid signature allowing the rest of the TLS negotiation to progress.

How to Verify Your Java is Vulnerable to Psychic Signatures Vulnerability?

If you want to test ECDSA implementation on your Java application, there is an excellent project Project Wycheproof, a project developed and maintained by members of the Google Security Team.

Project Wycheproof is an open-source project that tests crypto libraries against known attacks. It contains a suite of tests for various cryptographic algorithms and implementations. Project Wycheproof helps library authors to ensure that their code is secure and helps users to check whether their crypto libraries are vulnerable to common attacks.

The Project Wycheproof test suite available on GitHub contains a list of supported libraries and algorithms, as well as information on how to contribute test cases.

How to Fix CVE-2022-21449- Psychic Signatures Vulnerability in Java?

1. The original implementation of ECDSA is not vulnerable. This loophole is created when the EC code is rewritten during the release of Java 15. This shows that the versions earlier than 15 are not vulnerable to this flaw.
2. This doesn’t mean that you should plan for roll back to versions less than 15. Oracle has fixed bug in its April 2022 Critical Patch Update and released the Java SE Development Kit 18.0.1 and 17.0.3. We recommend to upgrade any Java application running on Java 15, 16, 17, or 18 version to v18.0.1 and 17.0.3.
3. If you use Oracle GraalVM Enterprise Edition, then you should upgrade to v22.1
4. For all your third-party applications and services, please get in touch of your vendors and ensure that all their applications and services have patched and fixed the CVE-2022-21449 vulnerability.
5. Consider if you truly need a digital signature. Would a less complicated method suffice? MAC algorithms like HMAC are considerably more difficult to botch than signature schemes. If you must use a signature, consider using a modern algorithm such as EdDSA that avoids some of ECDSA’s problems.

How to fix Psychic Signatures Vulnerability in Java?

In this tutorial, we are going to show you how to fix CVE-2022-21449 by upgrading Oracle Java v17.0.2 to v17.0.3 on Ubuntu platform.

How to migrate to Different version of  Java or JDK?

In the previous section, we showed how to upgrade the Java to the next version (from v17.0.2 to v17.0.3). However, in this section, we will show you how to migrate from Java v17.x to v18.x. This method is the universal method, you can apply this to migrate between Oracle Java to OpenJDK or visa-versa.

Step 1: Download the JDK 18.0.1 (Latest at the time of writing this post)
$ wget –no-check-certificate https://download.oracle.com/java/18/archive/jdk-18.0.1_linux-x64_bin.deb

Step 2: Set execution permission
$ chmod +x jdk-18.0.1_linux-x64_bin.deb

Step 3: Install the Java deb package
$ sudo apt install /home/arunkl/jdk-18.0.1_linux-x64_bin.deb

Step 4: Set the new Java path as a environment variable
$ sudo nano /etc/environmentPATH=”:/usr/lib/jvm/jdk-18/bin”JAVA_HOME=”/usr/lib/jvm/jdk-18″

Step 5: Reboot the machine to save the changes or use source command to save the changes temporary
$ source /etc/environment$ echo $JAVA_HOME

Step 6: Set the new Java and Java compiner path directives
$ sudo update-alternatives –install “/usr/bin/java” “java” “/usr/lib/jvm/jdk-18/bin/java” 0
$ sudo update-alternatives –install “/usr/bin/javac” “javac” “/usr/lib/jvm/jdk-18/bin/javac” 0
$ sudo update-alternatives –set java /usr/lib/jvm/jdk-18/bin/java
$ sudo update-alternatives –set javac /usr/lib/jvm/jdk-18/bin/javac

Step 7: List the installed java and their paths
$ sudo update-alternatives –list java

Step 8: Change the default Java version
$ sudo update-alternatives –config java

That’s it. This is how you can migrate between different versions of Java.

We hope this post will help you know How to Fix CVE-2022-21449- Psychic Signatures Vulnerability in Java. Please share this post and help to secure the digital world. Visit our social media page on Facebook, LinkedIn, Twitter, Telegram, Tumblr, & Medium and subscribe to receive updates like this. 

• How To Fix Digital Signature Spoofing
• How To Fix Digital Signature Spoofing Vulnerabilities In LibreOffice- CVE-2021-25633, CVE-2021-25634, CVE-2021-25635?
• RCE Vulnerability In Control Web Panel
• Hackers And Pentesters!
• How To Fix CVE-2021-44832- A Remote Code Execution Vulnerability In Apache Log4j Library