RedHat has issued an advisory today (January 17): https://access.redhat.com/errata/RHSA-2018:0095 Corresponding Oracle CPU: http://www.oracle.com/technetwork/security-advisory/cpujan2018-3236628.html The update is not yet available in Fedora.
Assignee: bugsquad => javaCC: (none) => marja11
Nicolas, I just checked this update into SVN, but I'm again not able to update Source 4 as I keep getting 404 errors. Can you help with this?
CC: (none) => nicolas.salguero
(In reply to David Walser from comment #1) > Nicolas, I just checked this update into SVN, but I'm again not able to > update Source 4 as I keep getting 404 errors. Can you help with this? I was able to update Source 4 with the code from the official branch (http://hg.openjdk.java.net/jdk8u/jdk8u/jdk, release 161b12) as aarch64-port branch is not synced.
Thanks Nicolas! Advisory: ======================== Updated java-1.8.0-openjdk packages fix security vulnerabilities: 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: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-2579 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-2582 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-2588 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-2599 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-2602 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-2603 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-2618 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-2629 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-2633 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-2634 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-2637 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-2641 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-2663 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-2677 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-2678 http://www.oracle.com/technetwork/security-advisory/cpujan2018-3236628.html https://access.redhat.com/errata/RHSA-2018:0095 ======================== Updated packages in core/updates_testing: ======================== java-1.8.0-openjdk-1.8.0.161-1.b14.1.mga5 java-1.8.0-openjdk-headless-1.8.0.161-1.b14.1.mga5 java-1.8.0-openjdk-devel-1.8.0.161-1.b14.1.mga5 java-1.8.0-openjdk-demo-1.8.0.161-1.b14.1.mga5 java-1.8.0-openjdk-src-1.8.0.161-1.b14.1.mga5 java-1.8.0-openjdk-javadoc-1.8.0.161-1.b14.1.mga5 java-1.8.0-openjdk-accessibility-1.8.0.161-1.b14.1.mga5 java-1.8.0-openjdk-1.8.0.161-1.b14.1.mga6 java-1.8.0-openjdk-headless-1.8.0.161-1.b14.1.mga6 java-1.8.0-openjdk-devel-1.8.0.161-1.b14.1.mga6 java-1.8.0-openjdk-demo-1.8.0.161-1.b14.1.mga6 java-1.8.0-openjdk-src-1.8.0.161-1.b14.1.mga6 java-1.8.0-openjdk-javadoc-1.8.0.161-1.b14.1.mga6 java-1.8.0-openjdk-javadoc-zip-1.8.0.161-1.b14.1.mga6 java-1.8.0-openjdk-accessibility-1.8.0.161-1.b14.1.mga6 from SRPMS: java-1.8.0-openjdk-1.8.0.161-1.b14.1.mga5.src.rpm java-1.8.0-openjdk-1.8.0.161-1.b14.1.mga6.src.rpm
Whiteboard: (none) => MGA5TOOAssignee: java => qa-bugs
Installed and tested without issues. Tested using java based applications (e.g. netbeans, yuicompressor, htmlcleaner, projectlibre). Didn't do any CVE related tests. System: Mageia 6, x86_64, Plasma DE, LXQT DE, Intel CPU, nVidia GPU using nvidia340 proprietary driver. $ uname -a Linux marte 4.14.15-desktop-2.mga6 #1 SMP Wed Jan 24 23:42:14 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux $ rpm -qa | grep java-1.8.0-openjdk | sort java-1.8.0-openjdk-1.8.0.161-1.b14.1.mga6 java-1.8.0-openjdk-headless-1.8.0.161-1.b14.1.mga6
CC: (none) => mageia
MGA5-32 on Dell Latitude D600 Xfce No installation issues Ref bug 21903 Comment 8, I could see and validate my eid card at CLI: $ java -jar eid-viewer.jar OK for me
CC: (none) => herman.viaeneWhiteboard: MGA5TOO => MGA5TOO MGA5-32-OK
MGA6-32 on Dell Latitude D600 Xfce No installation issues Ref bug 21903 Comment 8, I could see and validate my eid card at CLI: $ java -jar eid-viewer.jar OK for me
Whiteboard: MGA5TOO MGA5-32-OK => MGA5TOO MGA5-32-OK MGA6-32-OK
Advisory committed to svn. Validating the update based on the above tests.
CC: (none) => davidwhodgins, sysadmin-bugsKeywords: (none) => advisory, validated_update
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2018-0104.html
Status: NEW => RESOLVEDResolution: (none) => FIXED