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 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 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 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 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.
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.
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.
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.
Oracle Java SE 7u91 and 8u65 fixes an unspecified vulnerability in the Deployment component (CVE-2015-4810). 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/cpuoct2015-2367953.html#AppendixJAVA
Oracle Java SE 7u91 fixes an unspecified vulnerability in the Libraries component (CVE-2015-4871). Upstream has CVSSv2 scored this issue as: 5.8/AV:N/AC:M/Au:N/C:P/I:P/A:N
External Reference:
http://www.oracle.com/technetwork/topics/security/cpuoct2015-2367953.html#AppendixJAVA
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.