Oracle CPU January 2018 Released

Customer Alert 20180116

Oracle Critical Patch Update January 2018 Released

Summary

The  Oracle CPU January 2018 contains 237 new security vulnerabilities across hundreds of Oracle products, including the company’s widely used Oracle Database Server and Java SE.  The CPU includes:

• Fixes for the Java Virtual Machine and three other vulnerable components within the Oracle Database Server, the most severe of which carries a CVSS Base Score of 9.1 out of 10; three of the flaws may be exploited remotely without credentials.
• New security fixes for 21 vulnerabilities in multiple versions of Java SE, 18 of which are remotely exploitable without authentication.  The most severe of the vulnerabilities in Java SE has a CVSS Base Score of 8.3. The CPU includes fixes for flaws in Java SE versions 6 through 9.
• More than 28% of the security fixes in Java SE are related to Java deserialization issues.
• Two deserialization vulnerabilities identified in the Java platform by Waratek are patched in the January 2018 CPU.
• The number of vulnerabilities patched in the Java platform have doubled since January 2016.

Commentary

While there is some good news in the January CPU – the number of overall bugs patched in the Update is down from the high of July 2017 – the number of Java flaws being found and fixed is flat quarter-over-quarter and has risen 2X since January 2016.  Equally troubling is the number of Java SE flaws that can be remotely exploited without credentials remains in the double digits after years of single digit risk.

Oracle has released one new public release for Java 9 and two separate public Java 8 releases, namely 9.0.4, 8u161 and 8u162. Apart from the security fixes for 21 vulnerabilities, each of these Java releases contains a different set of security bug fixes. More specifically, Java 9.0.4 contains 11 security bug fixes, 8u161 contains 13 bug fixes and 8u162 contains 63 bug fixes. Java 7 and Java 6 also received critical patch updates but these are only available to Oracle customers through Oracle’s paid support site.

Java deserialization vulnerabilities continue to be a key component of the January 2018 CPU. More than one fifth (28.5%) of the fixed vulnerabilities are related to Java deserialization issues. The majority of them are related to unbounded memory allocation vulnerabilities.

Additionally, the default values for the JEP-290 RMI Registry filter have changed because the previously default values were too restrictive. This was causing several incompatibility issues and broke legitimate application functionality. In the January 2018 CPU, Oracle has decided to relax the default maximum array size to 1,000,000, allowing the user to decrease it if needed.

Waratek recommends users decrease this number to the minimum value possible in their environments in order to reduce the risk of potential Denial of Service attacks via payloads that allocate extensive memory using RMI Registry components. In this release, Oracle also introduced a new specific deserialization filter that enables users to limit the classes that are allowed to be deserialized by the RMI Connector Server.

Waratek has also researched the JRE codebase and has identified two new unbounded memory allocation vulnerabilities (CVE-2018-2677) in two JRE subcomponents that may be remotely exploitable without authentication. More specifically, the vulnerable subcomponents are:

Note that applications do not have to use these components in order to be vulnerable to Denial-of-Service deserialization attacks. Any application that performs deserialization of untrusted data is vulnerable to the above mentioned DoS attacks.

Oracle has been struggling with deserialization issues in the JRE for more than a year now and the trend only seems to be increasing. More than 1/5th of this quarter’s Java CPU is focused on patching deserialization vulnerabilities.

The key takeaway from this CPU is simple.  The velocity and volume of Java software flaws continues to trend in the wrong direction.  One research report shows that 86% of the most severe patches require 30 days or more to apply, while another concludes that the average time to apply a patch is 90 days or longer.  In either event, that is an unacceptably long period of time given that attacks often commence within hours of the announcement of a new vulnerability.

It is increasingly easy to apply virtual patches that instantly protect vulnerable applications without requiring downtime, code changes or tuning.  Purpose-built lightweight plugin agents exist that can shorten the time to apply Java and .NET virtual patches that are the functional equivalent of the physical binary.  This allows App Sec and Dev teams to better prioritize which apps require a physical patch without the risk of breaking the app or being breached while waiting to deploy the necessary code changes.

Recommended Actions

Waratek customers should apply the virtual patches provided by Waratek to receive immediate protection without restarting their applications.  This includes virtual patches for the two deserialization CVEs identified by Waratek and included by Oracle in the January 2018 CPU.

Non-customers should apply the appropriate binary CPU as quickly as possible as more than 85% of the CVEs impacting Java users addressed in the January 2018 CPU can be remotely exploited without credentials.  Applying the physical CPU requires binary changes which increases the risk of incompatibilities and unexpected functionality failures. Therefore, organizations are advised to apply the CPU in QA and UAT environments before deploying it into production.

John Matthew Holt, Waratek’s Founder and Chief Technology Officer and Apostolos Giannakidis, Waratek’s Lead Security Architect contributed to this Alert.