Some versions of Java are affected by a critical vulnerability in the Elliptic Curve Digital Signature Algorithm (ECDSA) signature validation that would allow threat actors to digitally sign files and other data in the same way that a legitimate entity would. A hacker could pass off malicious downloads as if it were benign content without Java applications being able to identify the hidden activity.
All kinds of Java implementations could be compromised if this flaw is exploited, including fields such as encrypted communications, authentication tokens, code updates and others. Oracle fixed the bug, tracked as CVE-2022-21449, in its code in its quarterly security patch.
While Oracle had initially assigned this flaw a severity score of 7.5/10, cybersecurity specialists analyzed the report and concluded that the flaw merited a critical score of 10/10. In this regard, the researcher Thomas Ptacek considers this report as the “cryptographic error of the year”, given its exploitation conditions and problems derived from the attack.
The most surprising thing about this flaw is the easy exploitation, plus it is a mistake that is very obvious and that Oracle took a long time to address. This vulnerability reportedly arose when some of the shape verification code in Java 15 was rewritten from C++ to Java, including the ECDSA verification code.
ECDSA signatures are composed of a pair of numbers, called r and s. To verify a signature, the code performs some calculations involving a hash of the data, the public key of any organization or person who has used your digital signature, and the r and s numbers; one side of the equation uses r, the other r and s.
Both sides of this calculation must be equal for the signature to be properly verified; that implies that the data was digitally signed by the signer’s private key. If signature verification fails, that probably means whoever signed the data is not who they say they are, so the data shouldn’t be verified.
In theory, for a signature to be valid, the value of r and s cannot be 0, 0, since in the process these numbers are multiplied with other values. The error arose because, while the original C++ code verified that both r and s were not zero, the new Java code did not verify this condition. As you may know, any quantity multiplied by zero equals zero. When s has to divide a value by 0, the verification failure is triggered.
The flaw has already been addressed, so it is recommended to update as soon as possible.
To learn more about information security risks, malware variants, vulnerabilities and information technologies, feel free to access the International Institute of Cyber Security (IICS) websites.
He is a well-known expert in mobile security and malware analysis. He studied Computer Science at NYU and started working as a cyber security analyst in 2003. He is actively working as an anti-malware expert. He also worked for security companies like Kaspersky Lab. His everyday job includes researching about new malware and cyber security incidents. Also he has deep level of knowledge in mobile security and mobile vulnerabilities.
