Advisories ยป MGASA-2016-0359

Updated java-1.8.0-openjdk packages fix security vulnerability

Publication date: 25 Oct 2016
Type: security
Affected Mageia releases : 5
CVE: CVE-2016-5542 , CVE-2016-5554 , CVE-2016-5573 , CVE-2016-5582 , CVE-2016-5597

Description

It was discovered that the Hotspot component of OpenJDK did not properly
check arguments of the System.arraycopy() function in certain cases. An
untrusted Java application or applet could use this flaw to corrupt
virtual machine's memory and completely bypass Java sandbox restrictions
(CVE-2016-5582).

It was discovered that the Hotspot component of OpenJDK did not properly
check received Java Debug Wire Protocol (JDWP) packets. An attacker could
possibly use this flaw to send debugging commands to a Java program
running with debugging enabled if they could make victim's browser send
HTTP requests to the JDWP port of the debugged application
(CVE-2016-5573).

It was discovered that the Libraries component of OpenJDK did not restrict
the set of algorithms used for Jar integrity verification. This flaw could
allow an attacker to modify content of the Jar file that used weak signing
key or hash algorithm (CVE-2016-5542).

Note: After this update, MD2 hash algorithm and RSA keys with less than
1024 bits are no longer allowed to be used for Jar integrity verification
by default. MD5 hash algorithm is expected to be disabled by default in
the future updates. A newly introduced security property
jdk.jar.disabledAlgorithms can be used to control the set of disabled
algorithms.

A flaw was found in the way the JMX component of OpenJDK handled
classloaders. An untrusted Java application or applet could use this flaw
to bypass certain Java sandbox restrictions (CVE-2016-5554).

A flaw was found in the way the Networking component of OpenJDK handled
HTTP proxy authentication. A Java application could possibly expose HTTPS
server authentication credentials via a plain text network connection to
an HTTP proxy if proxy asked for authentication (CVE-2016-5597).

Note: After this update, Basic HTTP proxy authentication can no longer be
used when tunneling HTTPS connection through an HTTP proxy. Newly
introduced system properties jdk.http.auth.proxying.disabledSchemes and
jdk.http.auth.tunneling.disabledSchemes can be used to control which
authentication schemes can be requested by an HTTP proxy when proxying
HTTP and HTTPS connections respectively.
                

References

SRPMS

5/core