MGASA-2018-0218: copy-jdk-configs Mageia
CVSS: UnknownPublished
Published 04-05-2018Last modified 16-04-2026
Vulnerability summary
MGASA-2018-0218 is a vulnerability in copy-jdk-configs Mageia with no CVSS score yet.
CVSS score
Not scored
010
No CVSS score recordedEPSS score
Not scored
0%100%
No EPSS score yetKEVNot listedIn no KEV catalog
RansomwareNone recordedNo known use recorded
Public exploits0No public exploits recorded
Advisory lineage
Upstream 10 · Downstream 0Timeline
- 04-05-2018PublishedVulnerability first disclosed.
- 16-04-2026Last modifiedVulnerability information updated.
Description
Updated java-1.8.0-openjdk packages fix security vulnerabilities OpenJDK: incorrect handling of Reference clones can lead to sandbox bypass (Hotspot, 8192025) (CVE-2018-2814) OpenJDK: unrestricted deserialization of data from JCEKS key stores (Security, 8189997) (CVE-2018-2794) OpenJDK: insufficient consistency checks in deserialization of multiple classes (Security, 8189977) (CVE-2018-2795) OpenJDK: unbounded memory allocation during deserialization in PriorityBlockingQueue (Concurrency, 8189981) (CVE-2018-2796) OpenJDK: unbounded memory allocation during deserialization in TabularDataSupport (JMX, 8189985) (CVE-2018-2797) OpenJDK: unbounded memory allocation during deserialization in Container (AWT, 8189989) (CVE-2018-2798) OpenJDK: unbounded memory allocation during deserialization in NamedNodeMapImpl (JAXP, 8189993) (CVE-2018-2799) OpenJDK: RMI HTTP transport enabled by default (RMI, 8193833) (CVE-2018-2800) OpenJDK: unbounded memory allocation during deserialization in StubIORImpl (Serialization, 8192757) (CVE-2018-2815) OpenJDK: incorrect merging of sections in the JAR manifest (Security, 8189969) (CVE-2018-2790)
CVSS metrics
Risk metrics not yet published.
EPSS trend
No EPSS score has been published for this record yet.
Known exploited
Compare KEV catalogsNot in any of the 3 tracked catalogs.
Public exploits
0 foundNo public exploits indexed.
Weaknesses
CWE · root causeNo weakness data has been published for this record.
Affected systems
Mageia4 products
- copy-jdk-configs< 3.3-1.1.mga5
- java-1.8.0-openjdk< 1.8.0.171-1.b10.1.mga5
- copy-jdk-configs< 3.3-1.1.mga6
- java-1.8.0-openjdk< 1.8.0.171-1.b10.1.mga6
1 vendor · 4 products
References
4 linksRelated vulnerabilities
MGASA-2018-0104mageiajava-1.8.0-openjdk+1Updated java-1.8.0-openjdk packages fix security vulnerability
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).MGASA-2017-0460mageiacopy-jdk-configs+3Updated java-1.8.0-openjdk packages fix security vulnerabilities
Multiple flaws were discovered in the RMI and Hotspot components in
OpenJDK. An untrusted Java application or applet could use these flaws
to completely bypass Java sandbox restrictions. (CVE-2017-10285,
CVE-2017-10346)
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 message. A man-in-the-
middle attacker could possibly use this flaw to impersonate Kerberos
services to Java applications acting as Kerberos clients.
(CVE-2017-10388)
It was discovered that the Security component of OpenJDK generated weak
password-based encryption keys used to protect private keys stored in
key stores. This made it easier to perform password guessing attacks to
decrypt stored keys if an attacker could gain access to a key store.
(CVE-2017-10356)
A flaw was found in the Smart Card IO component in OpenJDK. An untrusted
Java application or applet could use this flaw to bypass certain Java
sandbox restrictions. (CVE-2017-10274)
It was found that the FtpClient implementation in the Networking
component of OpenJDK did not set connect and read timeouts by default.
A malicious FTP server or a man-in-the-middle attacker could use this
flaw to block execution of a Java application connecting to an FTP
server. (CVE-2017-10355)
It was found that the HttpURLConnection and HttpsURLConnection classes
in the Networking component of OpenJDK failed to check for newline
characters embedded in URLs. An attacker able to make a Java application
perform an HTTP request using an attacker provided URL could possibly
inject additional headers into the request. (CVE-2017-10295)
It was discovered that multiple classes in the JAXP, Serialization,
Libraries, and JAX-WS components of OpenJDK did not limit the amount of
memory allocated when creating object instances from the serialized
form. A specially-crafted input could cause a Java application to use an
excessive amount of memory when deserialized. (CVE-2017-10349,
CVE-2017-10357, CVE-2017-10347, CVE-2017-10281, CVE-2017-10345,
CVE-2017-10348, CVE-2017-10350)MGASA-2017-0233mageiacopy-jdk-configs+3Updated java-1.8.0-openjdk packages fix security vulnerabilities
It was discovered that the DCG 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 (CVE-2017-10102).
Multiple flaws were discovered in the RMI, JAXP, ImageIO, Libraries,
AWT, Hotspot, and Security components in OpenJDK. An untrusted Java
application or applet could use these flaws to completely bypass Java
sandbox restrictions (CVE-2017-10107, CVE-2017-10096, CVE-2017-10101,
CVE-2017-10089, CVE-2017-10090, CVE-2017-10087, CVE-2017-10111,
CVE-2017-10110, CVE-2017-10074, CVE-2017-10067).
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 (CVE-2017-10116).
It was discovered that the Nashorn JavaScript engine in the Scripting
component of OpenJDK could allow scripts 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
(CVE-2017-10078).
It was discovered that the Security component of OpenJDK could fail to
properly enforce restrictions defined for processing of X.509
certificate chains. A remote attacker could possibly use this flaw to
make Java accept certificate using one of the disabled algorithms
(CVE-2017-10198).
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 (CVE-2017-10115).
A covert timing channel flaw was found in the PKCS#8 implementation in
the JCE component of OpenJDK. A remote attacker able to make a Java
application repeatedly compare PKCS#8 key against an attacker controlled
value could possibly use this flaw to determine the key via a timing
side channel (CVE-2017-10135).
It was discovered that the BasicAttribute and CodeSource classes in
OpenJDK did not limit the amount of memory allocated when creating
object instances from a serialized form. A specially crafted serialized
input stream could cause Java to consume an excessive amount of memory
(CVE-2017-10108, CVE-2017-10109).
Multiple flaws were found in the Hotspot and Security components in
OpenJDK. An untrusted Java application or applet could use these flaws
to bypass certain Java sandbox restrictions (CVE-2017-10081,
CVE-2017-10193).
It was discovered that the JPEGImageReader implementation in the 2D
component of OpenJDK would, in certain cases, read all image data even
if it was not used later. A specially crafted image could cause a Java
application to temporarily use an excessive amount of CPU and memory
(CVE-2017-10053).MGASA-2017-0120mageiacopy-jdk-configs+1Updated java-1.8.0-openjdk packages fix security vulnerability
An untrusted library search path flaw was found in the JCE component of
OpenJDK. A local attacker could possibly use this flaw to cause a Java
application using JCE to load an attacker-controlled library and hence
escalate their privileges (CVE-2017-3511).
It was found that the JAXP component of OpenJDK failed to correctly
enforce parse tree size limits when parsing XML document. An attacker able
to make a Java application parse a specially crafted XML document could
use this flaw to make it consume an excessive amount of CPU and memory
(CVE-2017-3526).
It was discovered that the HTTP client implementation in the Networking
component of OpenJDK could cache and re-use an NTLM authenticated
connection in a different security context. A remote attacker could
possibly use this flaw to make a Java application perform HTTP requests
authenticated with credentials of a different user (CVE-2017-3509).
Note: This update adds support for the "jdk.ntlm.cache" system property
which, when set to false, prevents caching of NTLM connections and
authentications and hence prevents this issue. However, caching remains
enabled by default.
It was discovered that the Security component of OpenJDK did not allow
users to restrict the set of algorithms allowed 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-2017-3539).
Note: This updates extends the fix for CVE-2016-5542 released as part of
the MGASA-2016-0359 advisory to no longer allow the MD5 hash algorithm
during the Jar integrity verification by adding it to the
jdk.jar.disabledAlgorithms security property.
Newline injection flaws were discovered in FTP and SMTP client
implementations in the Networking component in OpenJDK. A remote attacker
could possibly use these flaws to manipulate FTP or SMTP connections
established by a Java application (CVE-2017-3533, CVE-2017-3544).MGASA-2017-0041mageiacopy-jdk-configs+1Updated java-1.8.0-openjdk packages fix security vulnerabilities
It was discovered that the RMI registry and DCG implementations in the
RMI component of OpenJDK performed deserialization of untrusted inputs.
A remote attacker could possibly use this flaw to execute arbitrary code
with the privileges of RMI registry or a Java RMI application
(CVE-2017-3241).
This issue was addressed by introducing whitelists of classes that can
be deserialized by RMI registry or DCG. These whitelists can be
customized using the newly introduced sun.rmi.registry.registryFilter
and sun.rmi.transport.dgcFilter security properties.
Multiple flaws were discovered in the Libraries and Hotspot components
in OpenJDK. An untrusted Java application or applet could use these
flaws to completely bypass Java sandbox restrictions (CVE-2017-3272,
CVE-2017-3289).
A covert timing channel flaw was found in the DSA implementation in the
Libraries component of OpenJDK. A remote attacker could possibly use
this flaw to extract certain information about the used key via a timing
side channel (CVE-2016-5548).
It was discovered that the Libraries component of OpenJDK accepted ECSDA
signatures using non-canonical DER encoding. This could cause a Java
application to accept signature in an incorrect format not accepted by
other cryptographic tools (CVE-2016-5546).
It was discovered that the 2D component of OpenJDK performed parsing of
iTXt and zTXt PNG image chunks even when configured to ignore metadata.
An attacker able to make a Java application parse a specially crafted
PNG image could cause the application to consume an excessive amount of
memory (CVE-2017-3253).
It was discovered that the Libraries component of OpenJDK did not
validate the length of the object identifier read from the DER input
before allocating memory to store the OID. An attacker able to make a
Java application decode a specially crafted DER input could cause the
application to consume an excessive amount of memory (CVE-2016-5547).
It was discovered that the JAAS component of OpenJDK did not use the
correct way to extract user DN from the result of the user search LDAP
query. A specially crafted user LDAP entry could cause the application
to use an incorrect DN (CVE-2017-3252).
It was discovered that the Networking component of OpenJDK failed to
properly parse user info from the URL. A remote attacker could cause a
Java application to incorrectly parse an attacker supplied URL and
interpret it differently from other applications processing the same URL
(CVE-2016-5552).
Multiple flaws were found in the Networking components in OpenJDK. An
untrusted Java application or applet could use these flaws to bypass
certain Java sandbox restrictions (CVE-2017-3261, CVE-2017-3231).
A flaw was found in the way the DES/3DES cipher was used as part of the
TLS/SSL protocol. A man-in-the-middle attacker could use this flaw to
recover some plaintext data by capturing large amounts of encrypted
traffic between TLS/SSL server and client if the communication used a
DES/3DES based ciphersuite (CVE-2016-2183).
This update mitigates the CVE-2016-2183 issue by adding 3DES cipher
suites to the list of legacy algorithms (defined using the
jdk.tls.legacyAlgorithms security property) so they are only used if
connecting TLS/SSL client and server do not share any other non-legacy
cipher suite.MGASA-2016-0359mageiajava-1.8.0-openjdkUpdated 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.