It was discovered that the JNDI comment of OpenJDK did not properly enforce the restriction controlled by the com.sun.jndi.ldap.object.trustURLCodebase system property. In certain cases, a Java LDAP client could unexpectedly load and execute code form an LDAP server.

A certificate verification flaw was found in the JSSE component of OpenJDK. No check was preformed during the TLS session resumption to ensure that the same endpoint identification algorithm had been used when originally opening the session as was required when resuming the session. In certain cases, this could lead to having TLS connection established without required server identity verification.

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 Scripting component of OpenJDK did not properly restrict access to scripting engine via Global object's engine variable when using Security Manager or class filtering. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.

It was discovered that the implementation of the PatternSyntaxException class in the Concurrency component of OpenJDK failed to sufficiently validate the 'index' value (to ensure it's not greater than the regular expression length) in the getMessage() method. An instance of the class with invalid index value, for example one created via deserialization on an untrusted input, could cause a Java application to use an excessive amount of memory.

Last updated 24 July 2024

It was discovered that the RMI component of OpenJDK enabled HTTP transport for RMI servers by default. This could possibly expose RMI services to attackers who can not connect to them directly by attacking web browsers of users able to directly connect to the services.

The fix for this issue disables the use of RMI HTTP transport by default. System properly java.rmi.server.disableIncomingHttp (with the default value of "true") can be used to enable HTTP transport.

It was discovered that the implementation of the PriorityBlockingQueue class in the Concurrency component of OpenJDK did not limit the amount of memory allocated when creating object instance from a serialized form. A specially-crafted input could cause a Java application to use an excessive amount of memory when deserialized.

It was discovered that the implementation of the TabularDataSupport class in the JMX component of OpenJDK did not limit the amount of memory allocated when creating object instance from a serialized form. A specially-crafted input could cause a Java application to use an excessive amount of memory when deserialized.

It was discovered that the implementation of the Container class in the AWT component of OpenJDK did not limit the amount of memory allocated when creating object instance from a serialized form. A specially-crafted input could cause a Java application to use an excessive amount of memory when deserialized.

It was discovered that the implementation of the NamedNodeMapImpl class in the JAXP component of OpenJDK did not limit the amount of memory allocated when creating object instance from a serialized form. A specially-crafted input could cause a Java application to use an excessive amount of memory when deserialized.

It was discovered that the implementation of the StubIORImpl class in the Serialization component of OpenJDK did not limit the amount of memory allocated when creating object instance from a serialized form. A specially-crafted input could cause a Java application to use an excessive amount of memory when deserialized.

It was discovered that deserialization of multiple classes in the Security component of OpenJDK did not properly ensure consistency of the instances created form the serialized form. A specially-crafted input could cause a Java application to use an excessive amount of memory when deserialized.

It was discovered that the Security component of OpenJDK did not restrict which classes could be used when deserializing keys form the JCEKS key stores. A specially crafted JCEKS key store could possibly use this flaw to execute arbitrary code with the privileges of an application reading data form the key store.

The fix adds support for a new security property jceks.key.serialFilter which can be used to specify classes that can be used when deserializing data from the JCEKS key stores.

Oracle Java SE 6u181 and 7u171 fixes an unspecified vulnerability in the Serialization component (CVE-2018-2657). Upstream has CVSS scored this issue as: 5.3/CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

External Reference:

http://www.oracle.com/technetwork/security-advisory/cpujan2018-3236628.html#AppendixJAVA

It was discovered that the LDAPCertStore class in the JNDI component of OpenJDK failed to securely handle LDAP referrals. An attacker could possibly use this flaw to make the LDAPCertStore fetch attacker-controlled certificate data.

It was discovered that the JMX component of OpenJDK failed to properly set the deserialization filter for the SingleEntryRegistry in certain cases. A remote attacker could possibly use this flaw to bypass intended deserialization restrictions.

It was discovered that the DHKeyAgreement and P11KeyAgreement implementations in the JCE component of OpenJDK did not guarantee sufficient strength of used keys to adequately protect generated shared secret. This could make it easier to break encryption by attacking key agreement rather than the encryption using the negotiated key.

The patch for this issue causes classes' method generateSecret(String algorithm) to fail unless it's call for "TlsPremasterSecret", or the "jdk.crypto.KeyAgreement.legacyKDF" system property is set to true.

It was discovered that the JGSS component of OpenJDK failed to properly handle GSS context in the native GSS library wrapper in certain cases. A remote attacker could possibly make a Java application using JGSS to use previously freed context.

It was discovered that the DerValue class in the Libraries component of OpenJDK failed to sufficiently limit the amount of memory allocated when reading DER (Distinguished Encoding Rules) encoded input. It could allocate a large amount of memory even when processing short input. A remote attacker could possibly use this flaw to make a Java application use an excessive amount of memory if it parsed attacker-supplied DER encoded input.

It was discovered that the DNS client implementation in the JNDI component of OpenJDK did not use random source ports when sending out DNS queries. This would make it easier for a remote attacker to spoof responses to those queries.

It was discovered that the LdapLoginModule class in the LDAP component of OpenJDK failed to properly encode special characters in user names when adding them to LDAP search query. A remote attacker could possibly use this flaw to manipulate LDAP queries performed by the LdapLoginModule class.

It was discovered that multiple encryption key classes (DESKey, DESedeKey, PBEKey, PBKDF2KeyImpl) in the crypto provider in the Libraries component of OpenJDK did not properly synchronize access to their internal key data from multiple threads. This could possibly cause a multi-threaded Java application to apply weak encryption to data because of use of key that was zeroed out during object finalization.

It was discovered that the implementation of the ArrayBlockingQueue class in the Libraries component of OpenJDK did not check that all assumed invariants were satisfied after creating object instance from a serialized form, leaving the instance in an inconsistent state. If a Java application deserialized a specially-crafted input, this could cause it to raise an unexpected exceptions or allocate an excessive amount of memory.

It was discovered that the implementation of the BasicAttributes class in the JDNI component of OpenJDK did not limit the amount of memory allocated when creating object instance from a serialized form. A specially-crafted input could cause a Java application to use an excessive amount of memory when deserialized.

An unspecified vulnerability in Oracle Java SE related to the Java SE, Java SE Embedded, JRockit Networking component could allow an unauthenticated attacker to cause a denial of service resulting in a low availability impact using unknown attack vectors.

It was discovered that the implementation of the JceKeyStore class in the Serialization component of OpenJDK did not limit the amount of resources allocated when reading serialized objects from a jceks key store. A specially-crafted key store file could cause a Java application to use an excessive amount of resources when used.

It was found that the HttpURLConnection and HttpsURLConnection classes implementations in the Networking component of OpenJDK failed to check for newline characters embedded in URLs. An attacker able to make a Java application to perform an HTTP request to an attacker provided URL could possibly inject additional headers into the request.

It was discovered that the implementation of multiple classes in the Serialization component of OpenJDK did not limit the amount of memory allocated when creating object instances from a serialized form. A specially-crafted input could cause a Java application to use an excessive amount of memory when deserialized.

Oracle Java SE 6u161, 7u151, and 8u141 fixes an unspecified vulnerability in the JAX-WS component (CVE-2017-10243). Upstream has CVSS scored this issue as: 6.5/CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:L

External Reference:

http://www.oracle.com/technetwork/security-advisory/cpujul2017-3236622.html#AppendixJAVA