Inconsistencies were found in the way the java.net.URI and com.sun.jndi.toolkit.url.URI classes in the JNDI component of OpenJDK parsed URI strings. These inconsistencies could be used to make a Java application accept invalid or malformed URI strings.

Parsing of URL strings in built-in JNDI providers were made more strict as part of the fix. For more information, see the following release notes for Oracle JDK 7u341, 8u331, 11.0.15, 17.0.3, 18.0.1:

https://www.oracle.com/java/technologies/javase/7-support-relnotes.html#JDK-8278972 https://www.oracle.com/java/technologies/javase/8u331-relnotes.html#JDK-8278972 https://www.oracle.com/java/technologies/javase/11-0-15-relnotes.html#JDK-8278972 https://www.oracle.com/java/technologies/javase/17-0-3-relnotes.html#JDK-8278972 https://www.oracle.com/java/technologies/javase/18-0-1-relnotes.html#JDK-8278972

It was discovered that the AnnotationInvocationHandler class in the Libraries component of OpenJDK did not properly convert an object argument into its textual representation, allowing calls to the overridable toString() method when generating an Exception.

A flaw was found in the SSL logger implementation in the JSSE component of OpenJDK. A malicious client could cause a Java application acting as TLS server to raise an unexpected exception during TLS handshake.

It was discovered that the default TLS cipher suite configuration in the JSSE component of OpenJDK preferred certain weak ciphers over stronger ciphers. This issue was addressed by:

- Preferring ciphers with forward secrecy. - Lowering priority of ciphers using RSA encryption key exchange. - Lowering priority of ciphers using SHA-1 hashing algorithm.

Upstream commit:

https://github.com/openjdk/jdk11u/commit/af4b37301d33723806c38cf8ae5d85b7fa7ef39f

A flaw was found in the way the RTFReader class implementation in the Swing component of OpenJDK handled style keyword parameters. A specially crafted Rich Text Format (RTF) file could cause a Java application using RTFReader to allocate an excessive ammount of memory and possibly terminate on out-of-memory condition.

A flaw was found in the way the Keytool component of OpenJDK handled X.509 certificates with validity period ending too far in the future, after year 9999. When such certificates were imported into a keystore, they could cause corruption of the keystore.

A flaw was found in the way the RTFParser class implementation in the Swing component of OpenJDK handled memory allocations. A specially crafted Rich Text Format (RTF) file could cause a Java application using RTFParser to allocate an excessive amount of memory and possibly terminate on out-of-memory condition.

A CRLF injection flaw was found in the Lightweight HTTP Server component of OpenJDK. The HttpServer implementation did not restrict the use of CR and LF characters in values for HTTP headers, possibly allowing HTTP response splitting attacks.

A regular expression denial of service flaw was found in the Concurrency component of OpenJDK. The use of overly complex regular expressions in java.utils.Scanner could cause a high CPU usage when Scanner was used on parse certain inputs.

A flaw was found in the Serialization component of OpenJDK. A reference to an uninitialized class descriptor encountered during object stream deserialization could cause an unexpected exception to be raised when processing an untrusted serialized input.

A flaw was found in the Security component of OpenJDK. It was discovered that the unmarshalKeyInfo() method of the DOMKeyInfoFactory class and the unmarshalXMLSignature() method of the DOMXMLSignatureFactory class could raise exceptions not declared as thrown by these methods when reading key info or XML signature data from XML input.

It was discovered that the Hotspot component of OpenJDK did not properly check for integer overflows when when optimizing code, leading to out-of-bounds access. An untrusted Java application or applet could use this flaw to bypass certain Java sandbox restrictions.

It was discovered that the Libraries component of OpenJDK failed to perform permission check when converting file system paths to URI in UnixUriUtils and WindowsUriSupport classes. An untrusted Java application or applet could use this flaw to bypass certain Java sandbox restrictions.

A flaw was found in the way the Libraries component of OpenJDK handled blacklists of untrusted certificates. Alternate certificate encodings were not considered, causing certain certificate fingerprints to not be blacklisted, possibly leading to untrusted certificates being accepted.

It was discovered that the NIO Buffer implementation in the Libraries component of OpenJDK contained a race condition affecting boundary checks. An untrusted Java application or applet could use this flaw to bypass certain Java sandbox restrictions.

It was discovered that the UnixUriUtils class in the Libraries component of OpenJDK did not properly check for invalid characters when performing URI to Path conversion. This could lead to creating Path objects with invalid paths.

A flaw was found in the Nashorn JavaScript engine in the Scripting component of OpenJDK. Processing of the forward references prior to checking for regular expression syntax errors could cause an unexpected exception to be raised when processing a specially crafted regular expression.

A flaw was found in the Nashorn JavaScript engine in the Scripting component of OpenJDK. The state machine of the regular expression Parser did not correctly handle empty string nodes in certain cases, which could cause an unexpected exception to be raised when processing a specially crafted regular expression.

A flaw was found in the way the TLS implementation in the JSSE component of OpenJDK re-used single null TLS sessions for new TLS connections. A remote attacker could possibly use this flaw to impact availability of a Java application providing TLS server.

It was discovered that the LDAP client implementation in the JNDI component of OpenJDK did not properly track whether a connection to a server uses TLS encryption, and consequently did not properly restrict the set of authentication mechanisms that were allowed to be used over an unencrypted connection. This could possibly lead to sending of plain text authentication credentials over an unencrypted connection.

An input validation flaw was found in the URL class implementation in the Networking component of OpenJDK. A URL class instance could have been created for a URL string containing invalid characters not permitted in URLs.

A flaw was found in the way the JSSE component of OpenJDK handled certificate status / OCSP stapling message during TLS handshake. A remote attacker could possibly use this flaw to gain access to certain sensitive information by manipulating TLS handshake messages.

It was discovered that crypto provider implementations in the JCE component of OpenJDK for crypto algorithms such as AES or SHA did not perform array bounds checks. This could lead to out-of-bounds access if compiler intrinsics were used instead of the Java runtime implementations of the specific operations.

An infinite loop flaw was found in the RIFF (Resource Interchange File Format) file format reader in the Sound component of OpenJDK. A specially crafted RIFF file could cause a Java application to enter an infinite loop while reading the RIFF file.

It was discovered that the AccessController class implementation in the Security component of OpenJDK failed, in certain cases, to consider the current context and correctly restrict privileges based on it. An untrusted Java application or applet could use this flaw to bypass certain Java sandbox restrictions.

The Elliptic Curve (EC) cryptography in the Security component of OpenJDK was modernized to use formulas that are more efficient, easier to implement, and offer greater resiliency against side-channel attacks (timing or cache).

For more detailed information, refer to upstream bug:

https://bugs.openjdk.java.net/browse/JDK-8208698

Upstream commit:

http://hg.openjdk.java.net/jdk/jdk/rev/752e57845ad2

OpenJDK can apply two different security meanings to the same wildcard dNSName SAN across certificate policy enforcement and hostname verification. During path validation, DNSName.constrains compares .foo.com and secret.foo.com literally and returns NAMESAMETYPE, so NameConstraintsExtension.verify does not reject the chain when secret.foo.com is an exact-host exclusion. Later, HostnameChecker interprets the same SAN as a wildcard template and accepts secret.foo.com for .foo.com.

It was discovered that the XMLEntityManager class implementation in the JAXP component of OpenJDK did not properly perform access checks. A Java application using SAX XML parser in certain configuration could be tricked into disclosing information when parsing a specially-crafted XML file.

A flaw was found in the way the XMLEntityScanner and XML11EntityScanner classes in the JAXP component of OpenJDK handled and normalized newlines in XML entities. A specially-crafted XML document could cause a Java application to enter an infinite loop when parsed.

It was discovered that the C1 compiler in the Hotspot component of OpenJDK did not correctly apply an unsigned integer left shift to calculate the actual address offset under certain conditions. This could lead to an integer overflow and out-of-bounds array access, potentially corrupting the JVM memory.