Customer Alert 20170719
Oracle Critical Patch Update October 2017 Released
Summary
The October 2017 Oracle Critical Patch Update (CPU) contains 252 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 five other vulnerable components within the Oracle Database Server, the most severe of which carries a CVSS Base Score of 8.8; two of the flaws may be exploited remotely without credentials.
- New security fixes for 22 vulnerabilities in multiple versions of Java SE, 20 of which are remotely exploitable without authentication. The most severe of the vulnerabilities in Java SE has a CVSS Base Score of 9.6.
- The first fixes for Java SE 9 are included in this release along with optional JCE Unlimited Strength Policy Files that are standard in Java 9 that add unrestricted cryptographic strengths for Java versions 6 through 8.
- Oracle fixed 79 vulnerabilities in the Java platform in 2017, an increase of 113% compared to last year.
Commentary
The new Oracle October 2017 CPU contains fixes for 22 Java SE vulnerabilities. More than 90% of the fixed flaws can be exploited remotely without authentication. Nearly 60% allow successful remote Denial of Service attacks that can severely impact service availability. More alarming is the fact that more than 72% of the vulnerabilities can be easily exploited since their attack complexity is low.
It is not a surprise that there are more newly identified deserialization and RMI vulnerabilities fixed in the Java Virtual Machine. There is an increasing trend of deserialization vulnerabilities in the Java Virtual Machine both in incidence and in impact. Looking at the trend, we see that in the January 2017 CPU there was one deserialization vulnerability that was fixed, in the July 2017 CPU there were four and now in the October CPU there are five.
The October 2017 Oracle CPU is the last scheduled for this year. Looking back at the Java SE fixes this year, Oracle fixed a total of 79 vulnerabilities. In 2016 Oracle fixed 37 vulnerabilities. This is a significant increase of fixed vulnerabilities of more than 113% and a net increase of 42 vulnerabilities in relation to 2016. This indicates that Oracle is both committed to increase the security of the Java platform, but also that the Java platform is increasingly putting users and organizations at great risk.
In the past 45 days, security teams have been inundated with routine and emergency security patches that provide a vivid reminder of how important it is to keep pace with vulnerability patches, the difficulty of timely patching, and the disastrous consequences of failing to do so. Just prior to the failure-to-patch-related Equifax breach, an independent researcher released details of an easily exploitable Apache Struts flaw included in every version of Struts since 2008.
IBM and Oracle also released out-of-cycle patches based on flaws that were so serious they could not wait for regular patch updates. And, just one day before the release of this Oracle CPU, two new widespread vulnerabilities – KRACK and ROCA – requiring immediate patching were announced by US CERT and by users of flawed Infineon chips, including Microsoft, Google, Lenovo, HP and Fujitsu. With each new in- and out-of-cycle patch comes the same recommendation that the “fixes contained in this Security Alert be applied without delay.” That often means days, weeks or months – if at all – before a patch can be fully deployed across an enterprise. In reality, it is all but impossible to maintain a posture of fixing every software flaw with a physical patch.
Recommended Actions
Waratek customers should apply the virtual patches provided by Waratek to receive immediate protection without restarting their applications.
Non-customers should apply the appropriate binary CPU as quickly as possible as more than 90% of the CVEs impacting Java users addressed in the October 2017 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.
Even though organizations are advised to apply the CPU urgently, this must be done with great caution. This CPU breaks backwards compatibility for specific cryptographic classes. Customers are advised to set the “jdk.security.legacyDSAKeyPairGenerator” system property if their applications make use of the DSAKeyPairGenerator class by the SUN cryptographic provider. Failing to do so risks breaking the application when applying the CPU
Final Thoughts
The Java Virtual Machine offers a big attack surface for deserialization vulnerabilities and playing the Whac-A-Mole game of constantly patching the vulnerable classes is not a viable or scalable solution. Runtime Virtualization offers a highly effective and a unique way to address deserialization vulnerabilities without making source code changes. Also, runtime virtualization and runtime component privilege de-escalation removes the need to patch vulnerable classes and, therefore, offers 0-day protection.
It is important to highlight that blindly applying physical patches should be avoided because of the high risks of breaking existing application functionality. Organizations should assess their attack surface and the effects of each individual patch.
However, the physical Oracle CPU is a monolithic patch that can only be applied in an all-or-nothing approach, giving no option to apply only the specific patches needed for each environment.
In the alternative, Runtime virtualization offers a secure-by-default platform that can protect against known classes of attacks as well as against 0-days with no source code changes. Additionally, Virtual Patching offers immediate remediation for each vulnerable component without disrupting business.
Apostolos Giannakidis, Waratek’s Lead Security Architect and John Matthew Holt, Waratek’s Founder and Chief Technology Officer contributed to this Alert.
