Major vulnerabilities for Java applications without Oracle’s critical patch update
Oracle’s announces last critical patch update for Java 7, while exposing a number of remotely executable security threats for Java applications.
Today’s critical patch update from Oracle has revealed a major vulnerability to JRE/JDK versions, whereby an attacker can gain remote access to a Java application without a username or password. This applies to all versions of Java that have not applied the latest quarterly patch.
The April 2015 collection of 98 patches covers a number of security vulnerabilities across a range of Oracle products including Java SE, the MySQL Suite and the Oracle Database Server.
14 of the 98 fixes are for Oracle Java SE, three of which have been ranked with the highest possible vulnerability (10.0) in the Common Vulnerability Scoring System (CVSS). Oracle states that the other vulnerabilities “can be exploited only through sandboxed Java Web Start applications and sandboxed Java applets”. However there are still 14 JRE and JDK vulnerabilities that can be remotely exploitable over a network without authentication, says Waratek CTO John Matthew Holt.
“The most serious kind of threats”
These weak spots potentially allow remote attackers to gain access or control an application without a username or password, which represents “the most serious kind of threats”, Holt says.
Oracle is making this the last security patch publicly available to users of Java 7, meaning that all kinds of new security threats are soon coming to all enterprises brave enough to stay with Java 7 and lower. As of today, Java 8 is the only Java platform version with active security measures. “This is huge news, and it is going to cause enormous headache and disruption to millions of application owners around the world,” Holt said.
Holt explains that legacy Java platform developers can choose either to “commence a full upgrade, retest, and redeploy lifecycle onto the latest Java SE 8 update, or install any of the new Java Container RASP (Runtime Application Self-Protection) technologies that will quarantine and protect the Java Platform and the entire application stack automatically.”
Either way, the Java platform’s rapid life cycle and Oracle’s ruthless forward drive means that millions of Java 7 applications will be left fending for themselves against code level vulnerabilities without any help from Oracle.
Update and patch ASAP
Oracle’s official stance is that the Java community needs to stay on actively-supported versions and apply Critical Patch Update fixes as soon as possible.
Oracle continues to periodically receive reports of malicious exploitation of vulnerabilities for which Oracle has already released fixes. In some instances, it has been reported that malicious attackers have been successful because customers had failed to apply available Oracle patches.
This isn’t Oracle’s first brush with major security vulnerabilities, and it won’t be the last. Last year numerous flaws in the JDK and Java in the browser caused half of security pros to doubt the security of Java apps and Mozilla to boycott Java in Firefox. The Java 8 release was also subject to major delays as a result of security issues. However, as Holt explains below in the full interview, Oracle isn’t to blame for Java’s vulnerability.
JAXenter: What do Java 7 developers need to do to ensure their applications aren’t vulnerable?
John Matthew Holt: Java 7 developers really have 2 main options. Either they commence a project to upgrade their application to use Java 8. Or alternatively they can adopt any of the new breed of Java RASP (Run-time Application Self Protection) technologies that can containerize and protect the JRE and application stack automatically.
“It’s a case of YMMV (your mileage may vary)”
For simple applications, upgrading to the latest patched update of Java 8 may not be too difficult and may move the application out of immediate-term danger. However when the next Java 8 CPU patches come out in July then they’ll have to go through the patch/upgrade cycle all over again. Larger and more complex applications may not have such an easy time and may have considerably more challenges upgrading in this way. It’s a case of YMMV (your mileage may vary).
Regardless of whether an application is updated to the latest Java 8 patched update or not, there are a range of Java RASP containerization technologies that are coming onto the market now that are able to provide a whole spectrum of “defense-in-depth” capabilities for applications far beyond anything that a JRE/JDK CPU patch update will ever provide.
For example things like full-scale Java containerization that protects an application stack against both “outside-in” (outsider) as well as “inside-out” (insider) attacks, runtime security forensics for stack-wide visibility into irregular application behavior, and automatic protection for many of the top SANS/OWASP vulnerabilities higher up the application stack like SQL Injection and Cross-Site Scripting (XSS).
Is Oracle leaving developers of its legacy platform behind? Or is the vulnerability just collateral damage in its latest innovation drive?
Oracle is not at fault here, indeed they have been doing fantastic work to respond to Java’s security problems while also moving language innovation forward. But the reality is that there is a long tail of vulnerabilities which make securing Java by patching alone ultimately untenable.
“Oracle is not at fault here”
Java 7 is not unique in this regard – for example there is one version of Java SE 6 that has 96 CVSS score 10 vulnerabilities (the worst possible kind) and over 200 vulnerabilities altogether.
Oracle is doing commendable work in managing the two conflicting pressures of language innovation and application security. Language innovation is extremely important and Oracle has responded admirably – the features introduced in Java 8 and the upcoming features in Java 9 will maintain the position of the Java Platform and the Java Virtual Machine as the most sophisticated application runtime environment in the world.
Regarding Java security, we are going to see the emergence of very advanced Java containerization and Java RASP technologies in the next few years that will transform the Java Platform from being one of the least secure to becoming one of the most secure application runtime environments in the world today. The next few years are going to be transformative for Java and Java security.