jdk7-openjdk: multiple issues

2016-08-05T00:00:00
ID ASA-201608-3
Type archlinux
Reporter Arch Linux
Modified 2016-08-05T00:00:00

Description

  • CVE-2016-3458 (sandbox restriction bypass)

It was discovered that the CORBA component of OpenJDK did not sufficiently restrict the use of custom ValueHandler when performing object deserialization. An untrusted Java application or applet could use this flaw to bypass certain Java sandbox restrictions.

  • CVE-2016-3500 (denial of service)

It was discovered that the JAXP component of OpenJDK did not enforce the maximum XML name limit (jdk.xml.MaxXMLNameLimit) when parsing namespace URIs in 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.

  • CVE-2016-3508 (denial of service)

It was discovered that the JAXP component of OpenJDK did not place a limit on the number of entity replacements performed 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. Updates correcting this issue address the problem by introducing a limit on the number of entity replacements that can be performed. The limit can be controlled using the jdk.xml.entityReplacementLimit system property.

  • CVE-2016-3550 (sandbox restriction bypass)

Integer overflow flaws were found in the way the Hotspot component of OpenJDK read bytecode from class files. An untrusted Java application or applet could use this flaw to bypass certain Java sandbox restrictions.

  • CVE-2016-3598 (sandbox restriction bypass)

A flaw was found in the way the dropArguments() method of the MethodHandles class in the Libraries component of OpenJDK handled its valueTypes argument. As it did not create a copy of the list, caller could modify it after it was checked by the dropArguments() method. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.

  • CVE-2016-3606 (sandbox restriction bypass)

It was discovered that the bytecode verifier in the Hotspot component of OpenJDK did not properly verify correctness of the bytecode in the loaded class files. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.

  • CVE-2016-3610 (sandbox restriction bypass)

It was discovered that the filterReturnValue() method of the MethodHandles in the Libraries component of OpenJDK did not properly check filter MethodHandle parameter count. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.