It was discovered that the StAX XML parser in the JAXP (Java API for XML Processing) component of OpenJDK failed to properly honor setting indicating (defined using isSupportingExternalEntities / ISSUPPORTINGEXTERNALENTITIES property) whether external XML entities should be processed. External parameter entities were processed even when the StAX parser was configured to not process external entities. An attacker able to provide a specially-crafted XML file to an application using StAX parser could use this flaw to perform XML eXternal Entity (XXE) attack.

It was discovered that the CipherInputStream class implementation did not properly handle certain exceptions. This issue could possibly allow attacker to affect integrity of the encrypted stream handled using this class.

It was discovered that the TLS/SSL implementation in the JSSE component of OpenJDK was vulnerable to the Triple Handshake attack. An insufficient check of server's identity during the renegotiation following session resumption could allow a malicious server to manipulate clients authenticated session with a different server if client certificate authentication was used.

Further details of the attacks are described on:

https://secure-resumption.com/

It was discovered that the LogRecord class could use incorrect class loader during deserialization. This could cause incorrect ResouceBundle class to be loaded when deserializing LogRecord. An untrusted Java application or applet could use this flaw to bypass certain Java sandbox restrictions.

A flaw was found in the way the ResourceBundle class in OpenJDK standard library handled certain resource bundle names. An untrusted Java application or applet could possibly use this flaw to initiate HTTP network requests, bypassing certain Java sandbox restrictions.

It was discovered that the Hotspot JVM in OpenJDK failed to properly perform boundary checks when reading BootstrapMethods attributes from the Java class files. A specially crafted class file could trigger JVM memory corruption.

A flaw was found in the Hotspot's, the OpenJDK's JVM, optimizing C2 compiler. A byte code with incorrect range checks could be generated in certain cases, making it possible for an untrusted Java application or applet to disclose portions of the JVM memory.

It was discovered that the Libraries component in OpenJDK failed to properly check permission of the code when setting resource bundles on the Logger class instances. An untrusted Java application or applet could possibly use this flaw to set resource bundle on system logger instance, making it possible to see or manipulate logs of privileged code, and hence bypass certain Java sandbox restrictions.

Unspecified vulnerability in Oracle Java SE 5.0u65, 6u75, 7u60, and 8u5 allows remote attackers to affect confidentiality via unknown vectors related to Swing.

Oracle Java SE 7u65 and 8u11 fixes an unspecified vulnerability in the Deployment component (CVE-2014-4220). Upstream has CVSSv2 scored this issue as: 5.0/AV:N/AC:L/Au:N/C:N/I:P/A:N

External Reference:

http://www.oracle.com/technetwork/topics/security/cpujul2014-1972956.html#AppendixJAVA

Oracle Java SE 7u65 and 8u11 fixes an unspecified vulnerability in the Deployment component (CVE-2014-4208). Upstream has CVSSv2 scored this issue as: 2.6/AV:N/AC:H/Au:N/C:N/I:P/A:N

External Reference:

http://www.oracle.com/technetwork/topics/security/cpujul2014-1972956.html#AppendixJAVA

Oracle Java SE 6u81, 7u65 and 8u11 fixes an unspecified vulnerability in the Deployment component (CVE-2014-4227). Upstream has CVSSv2 scored this issue as: 10.0/AV:N/AC:L/Au:N/C:C/I:C/A:C

External Reference:

http://www.oracle.com/technetwork/topics/security/cpujul2014-1972956.html#AppendixJAVA

Oracle Java SE 6u81, 7u65 and 8u11 fixes an unspecified vulnerability in the Deployment component (CVE-2014-4265). Upstream has CVSSv2 scored this issue as: 5.0/AV:N/AC:L/Au:N/C:N/I:P/A:N

External Reference:

http://www.oracle.com/technetwork/topics/security/cpujul2014-1972956.html#AppendixJAVA

It was discovered that the Libraries component did not properly restrict the use of privileged annotations. An untrusted Java application or applet could possibly use this flaw to bypass Java sandbox restrictions.

It was discovered that the Security component did not properly handle data related to TLS and elliptic curves. An unauthenticated remote attacker could exploit this to impact the availability of the Java Virtual Machine.

It was discovered that JavasunmanagementGcInfoBuildergetLastGcInfo0() may return unexpected values. An untrusted Java application or applet could possibly use this flaw to impact the integrity of the Java Virtual Machine.

It was discovered that the Security component did not prevent the instantiation of security services with a non-public constructor. An untrusted Java application or applet could possibly use this flaw to disclose sensitive information.

It was discovered that the Libraries component did not properly clone the interface array before passing it to proxy methods. An untrusted Java application or applet could possibly use this flaw to bypass intended security restrictions.

It was discovered that the protection of the SubjectDelegator class was insufficient. An untrusted Java application or applet could possibly use this flaw to disclose or modify data related to the class.

It was discovered that the Libraries component did not properly handle method invocations with an exhausted rank. An untrusted Java application or applet could possibly use this flaw to bypass Java sandbox restrictions.

It was discovered that the Hotspot component did not properly parse invalid generic attributes for fields and methods. An untrusted Java application or applet could possibly use this flaw to bypass Java sandbox restrictions.

It was discovered that the event logger contains a format string error. An untrusted Java application or applet could possibly use this flaw to cause the Java Virtual Machine to crash, or, potentially, execute arbitrary code with the privileges of the Java Virtual Machine.

It was discovered that the bytecode verification did not properly prevent ctor calls to this() and super() from certain code constructs. An untrusted Java application or applet could possibly use this flaw to bypass Java sandbox restrictions.

It was discovered that MethodHandles.Lookup did not properly check for "protected" modifier, making it possible to access protected constructors in a different package. An untrusted Java application or applet could use this flaw to bypass certain Java sandbox restrictions.

The Diffie-Hellman (DH) key exchange algorithm implementation in the OpenJDK Security component failed to validate public Diffie-Hellman parameters properly. This could allow OpenJDK implementation to accept and use weak parameters, making it possible for attackers to recover the negotiated key.

It was discovered that the RSA algorithm in the OpenJDK Security component did not sufficiently preform "blinding" while performing operations using private keys. An attacker able to measure timing differences of those operations could possibly leak information about the keys used.

Florian Weimer discovered that AtomicReferenceFieldUpdater in OpenJDK does not properly check if the field to be updated is of primitive type. An untrusted Java application or applet could use flaw to trigger Java virtual machine memory corruption and possibly bypass Java sandbox restrictions.

AtomicReferenceFieldUpdater API documentation: http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.html

This issue is mitigated by the bug that prevents AtomicFieldUpdater instances when code runs under security manager restrictions under OpenJDK and Oracle JDK 6 and 7. The bug was fixed in JDK8:

http://bugs.java.com/bugdatabase/viewbug.do?bugid=7103570 http://bugs.java.com/bugdatabase/viewbug.do?bugid=7131655 http://hg.openjdk.java.net/jdk8/tl/jdk/rev/48513d156965

Acknowledgement:

This issue was discovered by Florian Weimer of Red Hat Product Security.

It was discovered that DatagramSocket implementation in OpenJDK did not perform any packet source address checks for packets received on connected socket. This could cause an application using DatagramSocket to read a packet from the socket that originates from a different source to the one to which the socket was connected. This problem is caused by BSD socket API oddity, which returns packets form different source if they were queued before socket was connected.

This issue can make it easier to perform IP spoofing attacks, as it may allow packets to be processed by an application without packets actually having spoofed source address. It can also lead to limited security manager restrictions bypass.

http://docs.oracle.com/javase/7/docs/api/java/net/DatagramSocket.html

Acknowledgement:

This issue was discovered by Florian Weimer of Red Hat Product Security.