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 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.
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.
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.
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.
It was discovered that the password-based encryption (PBE) implementation in the Libraries component of OpenJDK specified incorrect key length. This could lead to generation of keys that were weaker than expected in certain cases.
It was discovered that the JPEG decoder in the AWT component of OpenJDK did not use correct buffer boundary in certain cases when decoding JPEG files. A specially crafted JPEG file could cause a Java application to corrupt its memory and possibly execute arbitrary code when opened. An untrusted Java application or applet could also use this flaw to bypass Java sandbox restrictions.
It was discovered that the StAX XML parser in the JAXP component of OpenJDK could do certain DTD processing even when DTD support was disabled via the javax.xml.stream.supportDTD system property. A specially crafted XML document could cause a Java application using JAXP to consume an excessive amount of memory and CPU time when parsed.
It was discovered that the JAXP component of OpenJDK did not enforce the maximum XML name limit (jdk.xml.MaxXMLNameLimit) when parsing XML files. A specially crafted XML document could cause a Java application using JAXP to consume an excessive amount of memory and CPU time when parsed.
It was discovered that the AlgorithmChecker class in the Security component of OpenJDK failed to properly check if a certificate satisfies all defined constraints in certain cases. This could cause a Java application to accept an X.509 certificate which does not meet requirements of the policy defined in the java.security file.
It was discovered that the JAXP component of OpenJDK did not use efficient data structures to store data from parsed XML documents. A specially-crafted XML input could cause a Java application using JAXP to use an excessive amount of CPU time by e.g. triggering hash collisions.
A flaw was found in the way the Libraries component of OpenJDK verified OCSP (Online Certificate Status Protocol) response. An OCSP response with no nextUpdate date specified was incorrectly handled as having unlimited validity. This could allow a Java application to accept a revoked X.509 certificate as valid if it was presented with an OCSP response generated before certificate revocation.
A flaw was found in the way the JSSE component in OpenJDK performed X.509 certificate identify verification when establishing TLS/SSL connection to a host identified using IP address. In certain cases, it would incorrectly use a host name obtained after performing reverse DNS lookup of the specified IP address rather than the original IP address for the identity check, possibly leading to having a certificate issued for different identity to be accepted as valid.
This issue is know to affect cases when SSLSocketFactory.createSocket() is called with certain InetAddress instances. It is not known to affect cases when target host IP is passed to createSocket() as string, or when IP is used in URL used for HttpsURLConnection.
With this patch, reverse DNS lookup is no longer performed. The fix also adds new system property jdk.tls.trustNameService that can be used to allow the DNS lookup to be performed and hence have its result used during identity check.
It was discovered that the JCE (Java Cryptography Extension) component in OpenJDK failed to use constant time comparisons in multiple cases. An attacker could possibly use these flaws to disclose sensitive information by measuring time used to perform operations using these non-constant time comparisons.
A flaw was found in the way the DER (Distinguished Encoding Rules) decoder in the Security component in OpenJDK handled negative length values. A specially crafted DER encoded input could cause a Java application to enter an infinite loop when decoded.
It was discovered that the URLStreamHandler class in the Networking component of OpenJDK failed to properly parse user info from the URL. A remote attacker could cause Java application to incorrectly parse attacker provided URL and interpret it differently from other applications processing the same URL.
It was discovered that the SMTP client implementation in the Networking component of OpenJDK failed to correctly handle sender and recipient addresses containing newline characters. A remote attacker could possibly use this flaw to manipulate an SMTP connection opened by a Java application if it could make it send an email to or from a specially crafted address.
It was discovered that the FTP client implementation in the Networking component of OpenJDK failed to correctly handle user inputs (e.g. usernames and passwords) containing newline characters. A remote attacker could possibly use this flaw to manipulate an FTP connection opened by a Java application if it could make it access a specially crafted FTP URL.
Blog posts were published that describe how to use this flaw to open ports on firewalls using active FTP connections:
http://blog.blindspotsecurity.com/2017/02/advisory-javapython-ftp-injections.html
and sending mails during XML parsing when use of XML external entities is allowed:
https://shiftordie.de/blog/2017/02/18/smtp-over-xxe/
It was found that the JAXP (Java API for XML Processing) component of OpenJDK failed to correctly enforce parse tree size limits when parsing XML document. An attacker able to make a Java application parse a specially crafted XML document could use this flaw to make it consume an excessive amount of CPU and memory.
Vulnerability in the Java SE component of Oracle Java SE (subcomponent: AWT). Supported versions that are affected are Java SE: 6u141, 7u131 and 8u121. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Java SE, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in takeover of Java SE. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.0 Base Score 8.3 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H).
A untrusted library search path flaw was found in the JCE (Java Cryptography Extension) component of OpenJDK, caused by a problem with the handling of paths to extension directories in the sun.misc.Launcher class. A local attacker could possibly use this flaw to cause a Java application using JCE to load an attacker-controlled library and therefore escalate their privileges.
It was discovered that the LdapLoginModule class in the Java Authentication and Authorization Service (JAAS) component of OpenJDK did not use a correct way to extract user DN from a result of the LDAP query used to locate user in an LDAP database. A specially crafted user LDAP entry could cause the application to use incorrect DN.
It was discovered that the PNGImageReader in the javax.imageio package of the 2D component of OpenJDK performed parsing of iTXt and zTXt PNG image chunks even when ignoreMetadata was set to true. An attacker able to make a Java application parse a specially crafted PNG image could cause the application to consume an excessive amount of memory.
It was discovered that the RMI registry and DCG (Distributed Garbage Collector) implementations in the RMI component of OpenJDK performed deserialization of untrusted inputs. A remote attacker could possibly use this flaw to execute arbitrary code with the privileges of RMI registry or a Java RMI application.
It was discovered that the RMI (Java Remote Method Invocation) server implementation in the JMX (Java Management Extensions) component of OpenJDK did not restrict which classes can be deserialized when deserializing authentication credentials. A remote unauthenticated attacker able to connect to a JMX port could possibly use this flaw trigger deserialization flaws.
It was discovered that the JPEG decoder did not properly handle certain input streams. An untrusted Java application or applet could possibly use this flaw to trigger a Java Virtual Machine memory corruption.
It was discovered that the fix for CVE-2013-5797 (bug 1018720) did not properly with the issue in the way javadoc (Java API Documentation Generator) created a JavaScript code used to set browser window title when navigating between pages of the generated API documentation. An input from user was not properly escaped before being used as part of the JavaScript string. A specially crafted input could "break out" of the JS string and execute arbitrary JavaScript in the context of the domain that hosts generated API documentation, allowing a Cross-Site Scripting attacks.
The original fix for the issue added escaping of quotes and non-ASCII characters, but it failed to escape HTML special characters < and >.
Acknowledgement:
This issue was discovered by the Red Hat Security Response Team.
It was discovered that the JNDI DNS client did not properly randomize the DNS query ID. A remote attacker could exploit this flaw to e.g. perfom DNS spoofing attacks.
It was discovered that the System.arraycopy() method has a race condition between verifying source elements and storing them. An untrusted Java application or applet could possibly use this flaw to trigger a Java Virtual Machine memory corruption.
It was discovered that the ServiceLoader did not perform exception handling in a secure manner. An untrusted Java application or applet could possibly use this flaw to bypass security mechanisms and perform operations with full permissions.