Customer Alert 20170719

Another record number of critical patches shows the volume of software vulnerabilities continues to increase.

Summary

The July 2017 Oracle Critical Patch Update contains 32 Java-related CVEs, including:

• The 308 vulnerability fixes in the recent release is the largest ever in a single CPU; 2.3X the 136 vulnerabilities patched in the April 2016 CPU.

• The vast majority of the flaws – 87.5% – can be remotely exploited without authentication.

• 66% are high severity (CVSSv3 base score 7 – 10).

• 31% are medium severity (CVSSv3 base score 4 – 6.9),

• The highest CVSS affecting Java SE is 9.6

• 300% increase in fixed Java SE vulnerabilities compared to the April CPU

Commentary

For the second time this year, the latest Oracle patch release has reinforced the accelerating challenges cybersecurity teams face in keeping pace with software flaws and the malicious hackers that exploit them. The 308 overall fixes in this CPU is the largest single set of patches ever released by Oracle, more than double the 136 fixes issued just 15 months ago.

The vast number of vulnerabilities in the JRE included in this CPU demonstrates that the Java SE platform is still a very popular attack vector that allows applications and systems to be compromised by attacking the runtime itself. And, this trend keeps increasing at a fast rate. To put this into perspective, the July 2017 CPU fixes 300% more security vulnerabilities in Java SE compared to the April 2017 CPU.

It is not a surprise to see that a big number of the addressed vulnerabilities are related to the Security Manager and Java’s sandbox. These vulnerabilities are now added to the never-ending pile of the known vulnerabilities and limitations of Java’s sandbox.

The CPU includes fixes for numerous Java components including AWT, ImageIO, JavaFX, JAXP, ThreadPoolExecutor, AsynchronousChannelGroup, LambdaFormEditor, LDAP, Nashorn, JAR verifier, DSA, ECDSA, Elliptic Curve, X.509, PKCS#8, and even the HotSpot component.

The above vulnerabilities could allow attackers to escalate their privileges, corrupt the JVM’s memory, crash the JVM, or even to execute arbitrary code and system commands.

Finally, two new vulnerabilities were fixed in the Serialization component of the JVM that allows the excessive allocation of memory. It is worth noting here that this CPU also fixes deserialization vulnerabilities in the RMI and in the Distributed Garbage Collector despite the fact that the January 2017 report addressed deserialization vulnerabilities in the same components. This demonstrates that there are still critical deserialization attack vectors in the Java platform itself. It is apparent that Oracle is playing the Whac-A-Mole game with the deserialization vulnerabilities in the JVM internals.

Recommended Actions

Waratek actively protects against all CVEs that allow attackers to perform arbitrary Remote Command Execution (RCE) and deserialization attacks.

Waratek customers should apply the virtual patches provided by Waratek that address the remaining appropriate July CPU vulnerabilities to receive immediate protection without restarting their applications.

Non-customers should apply the appropriate binary CPU as quickly as possible as more than 87% of the CVEs addressed in the July 2017 CPU can be remotely exploited without credentials and 66% of the CVEs are classified as high severity. Applying the physical CPU requires binary changes which increase 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.

The July 2017 CPU blocks by default TLS server certificate chains with SHA-1 certificates. Users of applications that utilize such certificate chains must manually review the security properties in the java.security file of their JVMs to make sure that the defined restrictions work in their environments.

Additionally, the physical CPU requires applications to be restarted. If SLAs are important for organizations, then proper planning must be carried out to achieve the upgrade in a timely and orchestrated manner.

Final Thoughts

Since the April 2017 Oracle CPU, the world has been rocked by global malware attacks that exploit well-known flaws that have readily available fixes. Over-burdened and under resourced security teams simply cannot apply physical patches fast enough to stay ahead of the attackers. And, businesses rely on legacy applications that can’t be patched or upgraded, creating yet another avenue of attack. Now this CPU introduces a new range of flaws for hackers to try to exploit before cyber professionals can plug the holes over the coming months (or year).

The best hope for beating hackers to the punch is to utilize secure-by-default runtime platforms as well as to adopt a virtual patching scheme using automated tools that also upgrade and update legacy applications – increasing security and app efficiency in the process.