Java Security Is Getting Better

Java security has been in the spotlight this year, first because of hackers’ frequent use of Java applets to get onto end-user systems (Microsoft reported in 2013 that over 30% of all web based attacks make use of Java applets). Also, there are concerns about the end-of-life of Java 6, whose public version is now frozen at Java 6u45 from April 2013. Most recently, security researchers at F-Secure reported on the discovery of the first public exploits against vulnerabilities (CVE-2013-2463 and CVE-2013-2470) present in Java 6u45, but they remain unfixed due to its end-of-life status.

The best solution continues to be to update to the latest version of Java, which is Java 7 update 40 as of this week, because it addresses all the known vulnerabilities. At the same time many users continue to have Java 6 installed on their machines, mostly due to internal application requirements. According to our data, just over 50% of computers in corporations are still running Java 6, putting that version of Java in one of the top spots in our most critical vulnerability rankings. On the consumer side, things look much better. The visitors to our browser security service BrowserCheck have a much lower incidence of Java 6, at just under 9%, with values steadily declining since January 2013.

But Java 7 update 40 has a new feature that could be a solution even for organizations that are forced to run Java 6 to satisfy an internal application requirement. Java 7 now offers “Deployment Rule Sets,” which can be used to implement whitelisting. Together with a configuration where multiple Java versions are installed side-by-side, deployment lists can be used to have Java 7 server as the gatekeeper of all Java applications in the browser, capable of directing a certain subset (by URL or IP address, for example) to the legacy Java 6 version required. With this setup, IT administrators should be able to get the best of both worlds — an updated Java as the primary interface to the Internet and the required legacy support for certain applications. There are multiple configuration steps necessary to get this setup implemented, and editing of XML files, signing of files and distribution of files is involved. So it seems that this feature, at least at the moment, is not entirely straightforward. It will not change Java security overnight, but is a step in the right direction and I am sure that as the technology matures the setup process will become easier.

Let me know if you are trying this out. I would love to hear about your experiences. Stay tuned to this blog, as we will update this post as we get more information.

On a side note, this year, for the first time, there will be a security track at the JavaOne conference, which happen later this month in San Francisco.