Java 7u11 - Safer to switch to 6?

Question

Java update 7u11 has made some news lately for a couple reasons. Firstly, it was an out-of-band patch to resolve vulnerabilities being exploited in the wild. Then it came back up because it is now being found that the patch is incomplete. News I'm reading now seems to indicate one or more of a few things are happening.

1. A vulnerability that was supposed to be patched in 7u11 was not really fixed at all.
2. New vulnerabilities have been found in 7u11.
   • It is not clear whether these are new to 7u11, or pre-existing vulnerabilities newly discovered.
3. Though there was some mitigating effort put into 7u11, new exploit methods (possibly coupled with new vulnerabilities) are allowing the vulnerability that was supposedly patched to be compromised.

The release notes for Java 7u11 point to only one vulnerability, CVE-2013-0422. This vulnerability appears to be exclusive to Java 7. Java 6 is still receiving updates until February 2013, though.

If removing Java entirely is not an option, would switching to the latest version of Java 6 be safer for now? Or, are there enough vulnerabilities left un-patched in Java 6 that are resolved in 7 such that the newer version is still the lesser of the two evils?

Answer 1

I'd hazard a guess no. Not based on hard evidence, just a misgiving I have about rolling back to software that might not receive the latest fixes (previous versions eventually go on the "just update" pile), especially if you are a high value target.

One thing 7u11 has done is this:

Area: deploy Synopsis: Default Security Level Setting Changed to High The default security level for Java applets and web start applications has been increased from "Medium" to "High". This affects the conditions under which unsigned (sandboxed) Java web applications can run. Previously, as long as you had the latest secure Java release installed applets and web start applications would continue to run as always. With the "High" setting the user is always warned before any unsigned application is run to prevent silent exploitation.

So - assuming there are no bugs in the signature checking code that allow you to get around this - actually 7u11 with a healthy dose of user education could remain safe provided attackers cannot get their hands on a valid certificate to sign their exploit with. Specifically, unsigned code will pop up with a "this code is untrusted" dialog a little like UAC does.

This, combined with something like NoScript to block these objects from loading initially, should mean users at least have to click once before an exploit is triggered.

This is good - and should hopefully apply to any future exploits, too.

---

My understanding of the exploit situation is taken from this blog post. The vulnerability that allowed for overwriting the securityManager has been fixed, but the vulnerability that allowed for an end user to obtain class names via Reflection that would normally be unavailable due to the security policy has not been fixed.

Finally, as an aside, I've experimented with the vulnerability on OpenJDK and found that this issue appears not to be present there - I get a "The MBean class could not be loaded" exception (Reflection not working).

Answer 2

It may be infact safe enough to go back to Java6; though with the history of Java across many of it's versions I personally will never trust any version of it again.

I wonder what is driving your question though; do you have a specific browser-based need for Java to be enabled? Generally you can disable Java in the browsers you use (as this is where it is generally exploited) and leave Java7 on the PC for programs that require it; as it's much less of a specific target when it's no longer accessible via a browser plugin.

Answer 3

I doubt anyone can give you an authoritative answer... but my gut reaction says, sticking with Java 7 feels to me like it's probably safer.

Right now, Java 7 requires you to click on an applet before it will start running. In contrast, with Java 6 the applet could run without requiring a user click. Thus, today attacking Java 7 requires finding both a vulnerability and mounting a little bit of social engineering to get the user to click on you. Granted, the social engineering part is not a super-high barrier, but I think it's worth something.