Arch Linux Security Advisory ASA-201608-3
========================================
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 : jdk7-openjdk
Type    : multiple issues
Remote  : Yes
Link    : https://wiki.archlinux.org/title/CVE

Summary
======
The package jdk7-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 "jdk7-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
=========
https://mail.openjdk.org/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