IBM JDK 8 SR5 FP30 (8.0.5.30) and IBM JDK 7R1 SR4 FP40 (7.1.4.40) fix a flaw described by upstream as:
Eclipse OpenJ9 is vulnerable to a buffer overflow, caused by improper bounds checking by the jiosnprintf() and jiovsnprintf() functions. By sending an overly long argument, a remote attacker could overflow a buffer and execute arbitrary code on the system or cause the application to crash.
OpenJ9 upstream bug and commit:
https://bugs.eclipse.org/bugs/showbug.cgi?id=543659 https://github.com/eclipse/openj9/commit/0971f22d88f42cf7332364ad7430e9bd8681c970
References:
https://www-01.ibm.com/support/docview.wss?uid=ibm10873332 https://developer.ibm.com/javasdk/support/security-vulnerabilities/#IBMSecurityUpdateMarch2019
IBM JDK 8 SR5 FP30 (8.0.5.30) fixes a flaw described by upstream as:
Eclipse OpenJ9 could allow a remote attacker to execute arbitrary code on the system, caused by the failure to omit a null check on the receiver object of an Unsafe call when accelerating it. An attacker could exploit this vulnerability to execute arbitrary code on the system.
OpenJ9 upstream bug:
https://bugs.eclipse.org/bugs/showbug.cgi?id=544019
Related OpenJ9 upstream commit seems to be:
https://github.com/eclipse/openj9/commit/531d3f96fe9cdcf6baad9f6d6837be8fbc805d8d
References:
https://www-01.ibm.com/support/docview.wss?uid=ibm10873332 https://developer.ibm.com/javasdk/support/security-vulnerabilities/#IBMSecurityUpdateMarch2019
Cobbler CobblerXMLRPCInterface object exposes all its functions over XMLRPC. This allows an attacker to use internal the internal functions of the class, such as creating a token, or upload files.
Upstream issue:
https://github.com/cobbler/cobbler/issues/1916
Upstream patch:
https://github.com/cobbler/cobbler/pull/1921
References:
https://movermeyer.com/2018-08-02-privilege-escalation-exploits-in-cobblers-api/
It was found that the Hotspot component of OpenJDK did not perform loader constraints checks in certain cases when handling ivokespecial JVM instruction. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.
A flaw was found in the privileged code used to handle unreferenced objects in the Target class in the RMI component of OpenJDK. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.
It was discovered that the implementation of the AsynchronousChannelGroupImpl class in the java.nio.channels package of the Libraries component of OpenJDK failed to properly perform access control checks. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.
It was discovered that the implementation of the ThreadPoolExecutor class in the java.util.concurrent package of the Libraries component of OpenJDK failed to properly perform access control checks. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.
It was discovered that the implementation of the ImageWatched class in the AWT component of OpenJDK failed to properly perform access control checks. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.
It was discovered that the implementation of the ActivationID class in the RMI component of OpenJDK failed to properly perform access control checks. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.
It was discovered that the implementation of the ServiceRegistry class in the ImageIO component of OpenJDK failed to properly perform access control checks. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.
It was discovered that the JAXP component of OpenJDK failed to restrict access to certain internal classes. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.
The fix for this issue adds the following packages to the package.access security property, which defines the list of restricted internal packages not accessible to untrusted code:
com.sun.org.apache.xml.internal.resolver.helpers. com.sun.org.apache.xml.internal.resolver.readers.
It was discovered that the implementation of the TransformerException class in the JAXP component of OpenJDK failed to properly perform access control checks, related to handling of the DTM exceptions. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.
Eclipse OpenJ9 could allow a local attacker to gain elevated privileges on the system, caused by the failure to performs an authorization check when an actor attempts to access a resource or perform an action. An attacker could exploit this vulnerability to gain access to diagnostic operations such as causing a GC or creating a diagnostic file.
It was discovered that the DCG (Distributed Garbage Collector) implementation in the RMI component of OpenJDK failed to correctly handle references. A remote attacker could possibly use this flaw to execute arbitrary code with the privileges of RMI registry or a Java RMI application.
It was discovered that the LDAPCertStore class in the Security component of OpenJDK followed LDAP referrals to arbitrary URLs. A specially-crafted LDAP referral URL could cause LDAPCertStore to communicate with non-LDAP servers.
Oracle Java SE 8u161 and 9.0.4 fixes an unspecified vulnerability in the Deployment component (CVE-2018-2638). Upstream has CVSS scored this issue as: 8.3/CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H
External Reference:
http://www.oracle.com/technetwork/security-advisory/cpujan2018-3236628.html#AppendixJAVA
Oracle Java SE 8u161 and 9.0.4 fixes an unspecified vulnerability in the Deployment component (CVE-2018-2639). Upstream has CVSS scored this issue as: 8.3/CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H
External Reference:
http://www.oracle.com/technetwork/security-advisory/cpujan2018-3236628.html#AppendixJAVA
It was discovered that the Nashorn JavaScript engine in the Scripting component of OpenJDK could allow JavaScripts to access Java APIs even when access to Java APIs was disabled. An untrusted JavaScript executed by Nashorn could use this flaw to bypass intended restrictions.
IBM JDK 7 SR10 FP45 (7.0.10.45), 7.1 SR4 FP45 (7.1.4.45), and 8 SR5 FP35 (8.0.5.35) fix a flaw described by upstream as:
Eclipse OpenJ9 is vulnerable to a denial of service, caused by the execution of a method past the end of bytecode array by the Java bytecode verifier. A remote attacker could exploit this vulnerability to cause the application to crash.
OpenJ9 upstream bug:
https://bugs.eclipse.org/bugs/showbug.cgi?id=545588
OpenJ9 upstream merge requests:
https://github.com/eclipse/openj9/pull/5528 https://github.com/eclipse/openj9/pull/5529
References:
https://www-01.ibm.com/support/docview.wss?uid=ibm10882850 https://developer.ibm.com/javasdk/support/security-vulnerabilities/#IBMSecurityUpdateApril2019
A flaw in the java.math component in IBM SDK, Java Technology Edition 6.0, 7.0, and 8.0 may allow an attacker to inflict a denial-of-service attack with specially crafted String data. IBM X-Force ID: 141681.
It was discovered that the Kerberos client implementation in the Libraries component of OpenJDK used the sname field from the plain text part rather than encrypted part of the KDC reply. A man-in-the-middle attacker could possibly use this flaw to impersonate Kerberos services to Java applications acting as Kerberos clients.
A covert timing channel flaw was found in the DSA implementation in the JCE component of OpenJDK. A remote attacker able to make a Java application generate DSA signatures on demand could possibly use this flaw to extract certain information about the used key via a timing side channel.
Note that the fix for this issue reverts the fix for CVE-2016-5548 (see bug 1413920) and uses different approach to implement blinding of the DSA operations.
It was discovered that the JAR (Java ARchive) verifier in the Security component of OpenJDK did not correctly handle files inside archives with missing digest. An attacker could possibly use this flaw to manipulate content of a singed JAR, bypassing intended verification.
Oracle Java SE 8u161 and 9.0.4 fixes an unspecified vulnerability in the Installer component (CVE-2018-2627). Upstream has CVSS scored this issue as: 7.5/CVSS:3.0/AV:L/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:H
External Reference:
http://www.oracle.com/technetwork/security-advisory/cpujan2018-3236628.html#AppendixJAVA
IBM JDK 8 SR5 FP20 (8.0.5.20), 7 R1 SR4 FP30 (7.1.4.30), 7 SR10 FP30 (7.0.10.30), and 6 SR16 FP70 (6.0.16.70) fix a flaw described by upstream as:
The IBM Java Runtime Environment's Diagnostic Tooling Framework for Java (DTFJ) does not protect against path traversal attacks when extracting compressed dump files.
References:
https://www-01.ibm.com/support/docview.wss?uid=ibm10719653 https://developer.ibm.com/javasdk/support/security-vulnerabilities/#IBMSecurityUpdateAugust2018
Last updated 24 July 2024
All builds of Eclipse OpenJ9 prior to 0.15 contain a bug where the loop versioner may fail to privatize a value that is pulled out of the loop by versioning - for example if there is a condition that is moved out of the loop that reads a field we may not privatize the value of that field in the modified copy of the loop allowing the test to see one value of the field and subsequently the loop to see a modified field value without retesting the condition moved out of the loop. This can lead to a variety of different issues but read out of array bounds is one major consequence of these problems.
Oracle Java SE 8u151 and 9.0.1 fixes an unspecified vulnerability in the Deployment component (CVE-2017-10309). Upstream has CVSS scored this issue as: 7.1/CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L
External Reference:
http://www.oracle.com/technetwork/security-advisory/cpuoct2017-3236626.html#AppendixJAVA
Oracle Java SE 6u161, 7u151, and 8u141 fixes an unspecified vulnerability in the JAX-WS component (CVE-2017-10243). Upstream has CVSS scored this issue as: 6.5/CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:L
External Reference:
http://www.oracle.com/technetwork/security-advisory/cpujul2017-3236622.html#AppendixJAVA
It was discovered that the Hotspot component of OpenJDK failed to properly validate uses of the invokeinterface Java Virtual Machine instruction. An untrusted Java application or applet could use this flaw to bypass certain Java sandbox restrictions.