Java's security dilemma: Old, vulnerable versions won't go away

Users of Java are caught between a rock and a hard place. They often need an older version of Java to run their applications, but those aged releases are susceptible to security breaches, which have plagued Java in recent years. Java accounted for 91 percent of Web exploits tallied -- and 14 percent of all successful PC exploits -- in Cisco Systems' recent 2014 Annual Security Report, far outpacing Adobe Flash and PDF documents, the other major "popular vectors for criminal activity," the report states. Specifically, Java on the client is the problem.

Oracle, which oversees Java, has stressed a need for users to upgrade to the latest version of Java to fend off security problems. Cisco also sees a benefit in upgrading to the latest Java version.

If only it were so easy.

An example of this dilemma is that 76 percent of companies using Cisco Web Security services are still running Java 6, which has reached its end of life and is unsupported. Because of application dependencies, many organizations have had no choice other than to stick with older Java versions despite the security risk they pose, therefore having to run, troubleshoot, and support multiple Java versions.

"Enterprises often use both versions of the Java Runtime Environment because different applications may rely on different versions to execute code," says the Cisco report. "However, with more than three-fourths of the enterprises surveyed by Cisco using an end-of-life [product] with vulnerabilities that may never be patched publicly, criminals have ample opportunity to exploit weaknesses."

Although it's not easy to upgrade applications so you can eliminate old versions of Java, Cisco and industry analysts offer some advice.

For applications still tied to older versions of Java, Levi Gundert, Cisco's senior threat researcher, advises that users revisit processes for upgrading proprietary applications to see if it can be done after all. He also recommends that, if necessary, companies invest resources to decrease the time it takes to complete an upgrade to Java after a patch is announced.

Jeffrey Hammond, an analyst at Forrester Research, offers three options:

1. Move up to Java 7 and budget for appropriate application testing and rollouts.
2. Pay Oracle for a support plan for Java 6 and get updates from MyOracle Support, in which Oracle is paid for back-patching.
3. Move off Java. Users could go to an open source platform that does not force upgrades through end-of-life policies, such as Linux or Node.js. Cisco's report also notes that disabling Java in browsers can prevent exploits while telemetry tools can monitor Java-associated traffic.

"All these scenarios involve different costs," Hammond says. "The least disruptive is No. 2." But the approach that "will keep this from happening to companies again in the future is No. 3."

Michael Cote, an analyst at 451 Research, emphasizes the need to patch, something that neither vendors nor IT like to do. "Well, it's annoying for Cisco and the users, but they somehow need to patch or replace the security problems they have," he says. "If there's some workaround, then they should document that. But when it comes to security holes in software, you have got to fix them."

The version dilemma is not unique to Java, of course. In the Microsoft world, apps tied to specific ActiveX and Internet Explorer versons pose the same dilemma -- and you can't run multiple IE versions simultaneously, as you can Java.

This story, "Java's security dilemma: Old, vulnerable versions won't go away," was originally published at InfoWorld.com. Get the first word on what the important tech news really means with the InfoWorld Tech Watch blog. For the latest developments in business technology news, follow InfoWorld.com on Twitter.