Update: Oracle has patched the CVE-2013-2463 vulnerability in Java 6 update 51, but this version is only available to subscribers of the commercial version of Java with the paid for Premier Support contract. If you depend on Java 6 in your organization you should investigate this support option.
Original: CVE-2013-2463 is a vulnerability in the Java 2D subcomponent, that was addressed by Oracle in the June 2013 Critical Patch Update for Java 7. Java 6 (including the latest u45) has the same vulnerability, as Oracle acknowledges in the CPU, but since Java 6 has become unsupported as of its End-of-Life in April 2013, there is no patch for the vulnerability.
It is, in essence, an implicit 0-day vulnerability: we know about its existence, but do not have a patch at hand. This happens each time a software package loses support and we track these instances in QualysGuard with our "EOL/Obsolete" detections, in this case:
QID: 105490 EOL/Obsolete Software: Oracle Java SE/JRE/JDK 6/1.6 Detected
But this time, things have become a bit more serious. As Matthew Schwartz reports in Informationweek, F-Secure has seen exploits for this vulnerability in Java 6 in the wild. Further they have seen it included in the Neutrino exploit kit, which guarantees that it will find widespread adoption. In addition, we still see very high rates of Java 6 installed (a bit over 50%), which means many organizations are vulnerable. We attribute this to the lock-in that organizations experience when they run software applications that require the use of Java 6.
Without doubt, organizations should update to Java 7 where possible, meaning that IT administrators need to verify with their vendors if an upgrade path exists. However I have talked to organizations that have pointed out that they cannot update or disable Java because it would affect business critical applications. So in essence they accept the risk of outdated Java in order to be able to continue to do business. Some of the organizations have moved to contain the use of Java (for example at Etsy), but that seems to be a rather rare effort.
For users of Java 6, it might be useful to look into the whitelisting of Java applets. Internet Explorer supports this out of the box through its concept of "Zones" and while it is not a perfect solution, it should deal with the most common attack vector – an applet embedded in a webpage. See our previous post on Java for some information on how to approach this.
We will keep you informed of any updates around the issue here on this blog.