Java vulnerabilities have hardly been out of the news during the last year. Here at DaniWeb we've covered a number of the stories as they surfaced: Java in the cross-hairs: the security debate rolls on, Is Java 7 still insecure? Oracle Patch doesn't fix underlying vulnerability, Update my insecure Java plug-in? Meh, say 72% of users and WARNING: New zero-day for Java 6u41 and Java 7u15. It's the latter two that are pertinent as to why I'm covering the whole Java exploits story again. It would appear that the CVE-2013-2463 vulnerability in the Java 2D subcomponent is still problematical, even though it was addressed in an Oracle patch for Java 7 back in June. Why so? Those previous stories give the clue: updating an insecure version of Java. In this case, Oracle has admitted that the same vulnerability exists for Java 6 but as it went end of life in April 2013, it's no longer supported and that means no patch.
This is what Wolfgang Kandek, CTO of Qualys, calls an implicit zero-day vulnerability. Think of this as being where a vulnerability is known but there is no available patch to prevent its exploitation. No surprise then, that security vendors have seen this Java 6 zero-day exploit in the wild and even, according to F-Secure, an inclusion for it in the Neutrino exploit kit. The trouble being, as Qualys points out, that instances of Java 6 installations are still running high: a little over 50% according to the monitoring that Qualys does. While business critical software still requires Java 6 in order to run, organizations will continue to use Java 6 - simple as.
I'm not saying this is a good thing, it quite patently isn't, but it is where the real world remains for now. Updating to Java 7 just isn't on the cards for everyone, and they will remain vulnerable to this exploit unless they take action. Qualys recommends, in the meantime, that users of Java 6 who cannot or will not upgrade should look into the whitelisting of Java applets. "Internet Explorer supports this out of the box through its concept of Zones" Kandek points out, adding "while it is not a perfect solution, it should deal with the most common attack vector - an applet embedded in a webpage."
