RHSA-2016:0650 — Security Advisory

An update for java-1.8.0-openjdk is now available for Red Hat Enterprise Linux 7.

Red Hat Product Security has rated this update as having a security impact of Critical. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.

The java-1.8.0-openjdk packages provide the OpenJDK 8 Java Runtime Environment and the OpenJDK 8 Java Software Development Kit.

Security Fix(es):

• Multiple flaws were discovered in the Serialization and Hotspot components in OpenJDK. An untrusted Java application or applet could use these flaws to completely bypass Java sandbox restrictions. (CVE-2016-0686, CVE-2016-0687)

• It was discovered that the RMI server implementation in the JMX component in OpenJDK did not restrict which classes can be deserialized when deserializing authentication credentials. A remote, unauthenticated attacker able to connect to a JMX port could possibly use this flaw to trigger deserialization flaws. (CVE-2016-3427)

• It was discovered that the JAXP component in OpenJDK failed to properly handle Unicode surrogate pairs used as part of the XML attribute values. Specially crafted XML input could cause a Java application to use an excessive amount of memory when parsed. (CVE-2016-3425)

• It was discovered that the GCM (Galois/Counter Mode) implementation in the JCE component in OpenJDK used a non-constant time comparison when comparing GCM authentication tags. A remote attacker could possibly use this flaw to determine the value of the authentication tag. (CVE-2016-3426)

• It was discovered that the Security component in OpenJDK failed to check the digest algorithm strength when generating DSA signatures. The use of a digest weaker than the key strength could lead to the generation of signatures that were weaker than expected. (CVE-2016-0695)

Note: If the web browser plug-in provided by the icedtea-web package was installed, the issues exposed via Java applets could have been exploited without user interaction if a user visited a malicious website.