Arch Linux Security Advisory ASA-201608-4 ========================================= Severity: Critical Date : 2016-08-05 CVE-ID : CVE-2016-3458 CVE-2016-3500 CVE-2016-3508 CVE-2016-3550 CVE-2016-3598 CVE-2016-3606 CVE-2016-3610 Package : jre7-openjdk Type : multiple issues Remote : Yes Link : https://wiki.archlinux.org/index.php/CVE Summary ======= The package jre7-openjdk before version 7.u111_2.6.7-1 is vulnerable to multiple issues including denial of service and sandbox restriction bypass. Resolution ========== Upgrade to 7.u111_2.6.7-1. # pacman -Syu "jre7-openjdk>=7.u111_2.6.7-1" The problems have been fixed upstream in version 7.u111_2.6.7. Workaround ========== None. 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. Impact ====== A remote attacker is able to perform a denial of service attack or bypass sandbox restrictions via various vectors. References ========== http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2016-July/036560.html https://access.redhat.com/security/cve/CVE-2016-3458 https://access.redhat.com/security/cve/CVE-2016-3500 https://access.redhat.com/security/cve/CVE-2016-3508 https://access.redhat.com/security/cve/CVE-2016-3550 https://access.redhat.com/security/cve/CVE-2016-3598 https://access.redhat.com/security/cve/CVE-2016-3606 https://access.redhat.com/security/cve/CVE-2016-3610