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 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 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 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.