An issue was discovered in libjpeg 9a and 9d. The allocsarray function in jmemmgr.c allows remote attackers to cause a denial of service (divide-by-zero error) via a crafted file.

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 JAXP component of OpenJDK did not properly count total size of the expanded general entities and therefore did not properly enforce the totalEntitySizeLimit limit. An attacker able to make a Java application parse a specially crafted XML file could use this flaw to make the application use and excessive amount of memory and possibly exit on out of memory condition.

JAXP XML parsing limits are described on the following page:

https://docs.oracle.com/javase/tutorial/jaxp/limits/limits.html

It was discovered that the RMIConnector and RMIConnectionImpl classes in the JMX component of OpenJDK could log sensitive information such as user passwords in its debug log, possibly leading the exposure of the information.

A flaw was found in the deserialization of the URL class in the Networking component of OpenJDK. Deserialization of the specially crafted data could result in creation of the URL object with an inconsistent state. An untrusted Java application or applet could use this flaw to bypass certain 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 RemoteObjectInvocationHandler class in the RMI component of OpenJDK did not check if object proxy is an instance of a proxy class and that it uses correct invocation handler. An untrusted Java application or applet could use this flaw to bypass certain Java sandbox restrictions by gaining access to data that should by protected by the sandbox.

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.

A flaw was found in the way the IIOPInputStream class in the CORBA component of OpenJDK performed deserialization of String objects. An untrusted Java application or applet could use this flaw to crash the Java Virtual Machine.

An information disclosure flaw was found in the JAXP component of OpenJDK. An untrusted Java application or applet could use this flaw to get information about user home directory location (the content of the "user.dir" system property), hence bypassing certain Java sandbox restrictions.

It was discovered that the 2D component of OpenJDK could perform out of bounds access and possibly disclose portions of the Java Virtual Machine memory when processing specially crafted color profiles. The issue was caused by having bundled lcms2 code use fast floor() implementation. An untrusted Java application or applet could use this flaw to bypass certain Java sandbox restrictions.

Andrea Palazzo reported the following problem affecting IcedTea-Web:

""" Using HTTPUrlConnection it is possible to set custom values for blacklisted headers, even if allowRestrictedHeaders is false, by supplying "Name:value" as name.

Also, if needed, trailing ":" could be stripped off using an array as header value. """

Acknowledgement:

Red Hat would like to thank Andrea Palazzo of Truel IT for reporting this issue.

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.

It was discovered that the JGSS component of OpenJDK did not properly hide Kerberos realm information from all error exceptions when running under Security Manager. An untrusted Java application or applet could use this flaw to obtain certain information about the Kerberos configuration on the host where they were executed, bypassing certain Java sandbox restrictions.

Oracle Java SE 6u101, 7u85 and 8u51 fixes an unspecified vulnerability in the Deployment component (CVE-2015-2664). Upstream has CVSSv2 scored this issue as: 6.9/AV:L/AC:M/Au:N/C:C/I:C/A:C

External Reference:

http://www.oracle.com/technetwork/topics/security/cpujul2015-2367936.html#AppendixJAVA

Oracle Java SE 6u101, 7u85 and 8u51 fixes an unspecified vulnerability in the 2D component (CVE-2015-2637). Upstream has CVSSv2 scored this issue as: 5.0/AV:N/AC:L/Au:N/C:P/I:N/A:N

External Reference:

http://www.oracle.com/technetwork/topics/security/cpujul2015-2367936.html#AppendixJAVA

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.

It was discovered that the RMIConnectionImpl class in the JMX component of OpenJDK failed to properly check code permissions when creating repository class loaders. An untrusted Java application or applet could use this flaw to read information access to which should be restricted by the Java sandbox, partially bypassing sandbox restrictions.

It was discovered that ICC profiles were not parsed correctly. An untrusted Java application or applet could possibly use this flaw to cause a denial of service.

In SQLite through 3.29.0 whereLoopAddBtreeIndex in sqlite3.c can crash a browser or other application because of missing validation of a sqlitestat1 sz field aka a "severe division by zero in the query planner."

A vulnerability was found in Hibernate-Validator. The SafeHtml validator annotation fails to properly sanitize payloads consisting of potentially malicious code in HTML comments and instructions. This vulnerability can result in an XSS attack.

Unspecified vulnerability in the Java SE, Java SE Embedded, JRockit component in Oracle Java SE 5.0u75, 6u85, 7u72, and 8u25; Java SE Embedded 7u71 and 8u6; and JRockit R27.8.4 and R28.3.4 allows remote attackers to affect availability via unknown vectors related to Security.

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. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Java SE accessible data.

Certificate chain validation can result in stack overflow under certain circumstances.

Easily exploitable vulnerability allows unauthenticated attacker with network access via TLS to compromise Java SE. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Java SE.

Difficult to exploit vulnerability allows unauthenticated attacker with network access via TLS to compromise Java SE. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Java SE accessible data.

Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Java SE.

Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Java SE.

Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Java SE accessible data as well as unauthorized read access to a subset of Java SE accessible data.