The java-1.8.0-openjdk packages provide the OpenJDK 8 Java RuntimeEnvironment and the OpenJDK 8 Java Software Development Kit.Multiple flaws were discovered in the 2D, CORBA, JMX, Libraries and RMIcomponents in OpenJDK. An untrusted Java application or applet could usethese flaws to bypass Java sandbox restrictions. (CVE-2015-4760,CVE-2015-2628, CVE-2015-4731, CVE-2015-2590, CVE-2015-4732, CVE-2015-4733)A flaw was found in the way the Libraries component of OpenJDK verifiedOnline Certificate Status Protocol (OCSP) responses. An OCSP response withno nextUpdate date specified was incorrectly handled as having unlimitedvalidity, possibly causing a revoked X.509 certificate to be interpreted asvalid. (CVE-2015-4748)It was discovered that the JCE component in OpenJDK failed to use constanttime comparisons in multiple cases. An attacker could possibly use theseflaws to disclose sensitive information by measuring the time used toperform operations using these non-constant time comparisons.(CVE-2015-2601)It was discovered that the GCM (Galois Counter Mode) implementation in theSecurity component of OpenJDK failed to properly perform a null check.This could cause the Java Virtual Machine to crash when an applicationperformed encryption using a block cipher in the GCM mode. (CVE-2015-2659)A flaw was found in the RC4 encryption algorithm. When using certain keysfor RC4 encryption, an attacker could obtain portions of the plain textfrom the cipher text without the knowledge of the encryption key.(CVE-2015-2808)Note: With this update, OpenJDK now disables RC4 TLS/SSL cipher suites bydefault to address the CVE-2015-2808 issue. Refer to Red Hat Bugzilla bug1207101, linked to in the References section, for additional details aboutthis change.A flaw was found in the way the TLS protocol composed the Diffie-Hellman(DH) key exchange. A man-in-the-middle attacker could use this flaw toforce the use of weak 512 bit export-grade keys during the key exchange,allowing them do decrypt all traffic. (CVE-2015-4000)Note: This update forces the TLS/SSL client implementation in OpenJDK toreject DH key sizes below 768 bits, which prevents sessions to bedowngraded to export-grade keys. Refer to Red Hat Bugzilla bug 1223211,linked to in the References section, for additional details about thischange.It was discovered that the JNDI component in OpenJDK did not handle DNSresolutions correctly. An attacker able to trigger such DNS errors couldcause a Java application using JNDI to consume memory and CPU time, andpossibly block further DNS resolution. (CVE-2015-4749)Multiple information leak flaws were found in the JMX and 2D components inOpenJDK. An untrusted Java application or applet could use this flaw tobypass certain Java sandbox restrictions. (CVE-2015-2621, CVE-2015-2632)A flaw was found in the way the JSSE component in OpenJDK performed X.509certificate identity verification when establishing a TLS/SSL connection toa host identified by an IP address. In certain cases, the certificate wasaccepted as valid if it was issued for a host name to which the IP addressresolves rather than for the IP address. (CVE-2015-2625)Multiple insecure temporary file use issues were found in the way theHotspot component in OpenJDK created performance statistics and error logfiles. A local attacker could possibly make a victim using OpenJDKoverwrite arbitrary files using a symlink attack. Note: This issue wasoriginally fixed as CVE-2015-0383, but the fix was regressed in theRHSA-2015:0809 advisory. (CVE-2015-3149)All users of java-1.8.0-openjdk are advised to upgrade to these updatedpackages, which resolve these issues. All running instances of OpenJDK Javamust be restarted for the update to take effect.