Advisories ยป MGASA-2018-0104

Updated java-1.8.0-openjdk packages fix security vulnerability

Publication date: 02 Feb 2018
Modification date: 02 Feb 2018
Type: security
Affected Mageia releases : 5 , 6
CVE: CVE-2018-2579 , CVE-2018-2582 , CVE-2018-2588 , CVE-2018-2599 , CVE-2018-2602 , CVE-2018-2603 , CVE-2018-2618 , CVE-2018-2629 , CVE-2018-2633 , CVE-2018-2634 , CVE-2018-2637 , CVE-2018-2641 , CVE-2018-2663 , CVE-2018-2677 , CVE-2018-2678

Description

Multiple flaws were found in the Hotspot and AWT components of OpenJDK. An
untrusted Java application or applet could use these flaws to bypass certain
Java sandbox restrictions (CVE-2018-2582, CVE-2018-2641).

It was discovered that the LDAPCertStore class in the JNDI component of
OpenJDK failed to securely handle LDAP referrals. An attacker could possibly
use this flaw to make it fetch attacker controlled certificate data
(CVE-2018-2633).

The JGSS component of OpenJDK ignores the value of the
javax.security.auth.useSubjectCredsOnly property when using HTTP/SPNEGO
authentication and always uses global credentials. It was discovered that this
could cause global credentials to be unexpectedly used by an untrusted Java
application (CVE-2018-2634).

It was discovered that the JMX component of OpenJDK failed to properly set the
deserialization filter for the SingleEntryRegistry in certain cases. A remote
attacker could possibly use this flaw to bypass intended deserialization
restrictions (CVE-2018-2637).

It was discovered that the LDAP component of OpenJDK failed to properly encode
special characters in user names when adding them to an LDAP search query. A
remote attacker could possibly use this flaw to manipulate LDAP queries
performed by the LdapLoginModule class (CVE-2018-2588).

It was discovered that the DNS client implementation in the JNDI component of
OpenJDK did not use random source ports when sending out DNS queries. This
could make it easier for a remote attacker to spoof responses to those queries
(CVE-2018-2599).

It was discovered that the I18n component of OpenJDK could use an untrusted
search path when loading resource bundle classes. A local attacker could
possibly use this flaw to execute arbitrary code as another local user by
making their Java application load an attacker controlled class file
(CVE-2018-2602).

It was discovered that the Libraries component of OpenJDK failed to
sufficiently limit the amount of memory allocated when reading DER encoded
input. A remote attacker could possibly use this flaw to make a Java
application use an excessive amount of memory if it parsed attacker supplied
DER encoded input (CVE-2018-2603).

It was discovered that the key agreement implementations in the JCE component
of OpenJDK did not guarantee sufficient strength of used keys to adequately
protect generated shared secret. This could make it easier to break data
encryption by attacking key agreement rather than the encryption using the
negotiated secret (CVE-2018-2618).

It was discovered that the JGSS component of OpenJDK failed to properly handle
GSS context in the native GSS library wrapper in certain cases. A remote
attacker could possibly make a Java application using JGSS to use a previously
freed context (CVE-2018-2629).

It was discovered that multiple classes in the Libraries, AWT, and JNDI
components of OpenJDK did not sufficiently validate input when creating object
instances from the serialized form. A specially-crafted input could cause a
Java application to create objects with an inconsistent state or use an
excessive amount of memory when deserialized (CVE-2018-2663, CVE-2018-2677,
CVE-2018-2678).

It was discovered that multiple encryption key classes in the Libraries
component of OpenJDK did not properly synchronize access to their internal
data. This could possibly cause a multi-threaded Java application to apply
weak encryption to data because of the use of a key that was zeroed out
(CVE-2018-2579).

References

SRPMS

5/core

6/core