The big ones get in trouble with the elliptical curves used in cryptographic operations for digital signatures: after the Microsoft Windows CryptoAPI bug earlier, now, with the announcement on the 19th of April, Oracle Java SE framework has also been dropped. The cryptographic experts at E-Group analyzed the error, which requires immediate intervention.
According to the bug ticket dropped (CVE-2022-21449), there are several vulnerabilities in Oracle’s solutions that validate ECDSA signatures in the Oracle Java SE framework.
According to CVE / NVD descriptions and other analyzes, the error is due to the lack of a 0-check when verifying elliptical curve digital signatures (i.e., ECDSA signatures based on NIST P-256 curve ASN.1 (r, s) or raw (r, s) values). Users rarely encounter such signing operations, but operations and messages in the background does:
- OASIS SAML protocol for XML Signature layers, OpenID Connect protocol for JWS (signed JWT) data (e.g. 3rd party Single Sign-On system);
- for document signatures (e.g. for smart card authenticated documents, X.509 certificates or system file “code signing” protection, which are also monitored and alerted by SIEM / SOC systems if an anomaly is detected);
- SSL / TLS handshake, i.e. in the construction of encrypted communication channels.
These are only the most important areas, but other protocols and data structures are also affected.
Using our own code, we examined the implications of different versions of Oracle Java SE for multiple data structures. Based on these, we can confirm that the previous Oracle Java SE 8 used in many legacy systems is not affected, but of the supported (LTS) versions, Oracle Java SE 17.0.2 and later all include exploitable vulnerabilities until April 2022 security patch will not be installed.
However, the involvement of a system is not easy to determine. The exploitation of the vulnerability depends not only on the version of Java running on the ECDSA signature verification side (e.g. Oracle Java SE 17.0.2) but also on the crypto library it uses (e.g. Bouncy Castle, Apache Santuario are not affected). In the case of the parties involved in the communication – servers, clients (mainly Java clients using a machine interface) – the review is only possible with the involvement of the operation administrators, possibly the developers, but the point is to switch to a flawless Java version and crypto library as soon as possible.
We encourage everyone to consult with their developers or even the professionally trained cryptographic team of E-Group welcomes all inquiries.