MGASA-2016-0359

Advisory lineage Upstream: 5 Downstream: 0
Published: 25 Oct 2016, 23:11
Last modified:16 Apr 2026, 06:25

Vulnerability Summary

Overall Risk (default)
minimal
0/100
CVSS Score
No data
EPSS Score
No data
KEV
Not listed
Ransomware
No reports
Public exploits
None found
Dark Web
Not detected

Timeline

25 Oct 2016, 23:11
Published
Vulnerability first disclosed
16 Apr 2026, 06:25
Last Modified
Vulnerability information updated

Description

Updated java-1.8.0-openjdk packages fix security vulnerability 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.

Affected Systems

  • mageiajava-1.8.0-openjdk

    < 1.8.0.111-1.b16.1.mga5

References (4)