Has Oracle’s Java 7 update patch finally removed the security vulnerabilities that have been exploited by hackers?

It’s been a torrid old time for Oracle over the last few months. Targeted by hackers, Oracle has rarely been out of the news. There were hopes that the recently-released Java 7 Update 11 would solve the problems once and for all, unfortunately the patch, which was meant to mitigate two zero-day vulnerabilities in Java that were being actively exploited by attackers, has not delivered according to cyber-security experts. They maintain that all that has happened is that the threat has been relocated, and therefore that Java is still vulnerable.

Java bug hunter, Adam Gowdiak, of Security Explorations in Poland was quoted on InformationWeek Security claiming that he has now discovered two new vulnerabilities in Java standard edition:

“We have successfully confirmed that a complete Java security sandbox bypass can still be gained under the recent version of Java 7 Update 11 (JRE version 1.7.0_11-b21),” he wrote in a post to the Full Disclosure mailing list. The new findings would appear to mean that as a result any attacker who used these vulnerabilities would be able to craft malware that tapped the Java runtime- environment, thereby fully compromising an already vulnerable system.

What is of interest is that these two newly discovered bugs have nothing to do with Oracle’s partial patch of the “MBeanInstantiator” flaw. This was addressed by Oracle by changing the default Java security setting from medium to high, which required that unsigned Java Web apps be authorized by a user before being allowed to run. Gowdiak added:

“The MBeanInstantiator bug (or rather a lack of a fix for it) turned out to be quite inspirational for us. However, instead of relying on this particular bug, we have decided to dig for our own issues. As a result, two new security vulnerabilities (51 and 52) were spotted in a recent version of Java SE 7 code and they were reported to Oracle today (along with a working Proof of Concept code).”

Gowdiak has numbered the security vulnerabilities 51 and 52, because that’s the total number of Java 7 bugs Security Explorations has reported to Oracle since April 2, 2012. Gowdiak told InformationWeek Security that the company has agreed to investigate the latest vulnerabilities based on the data provided and will report back soon. Security Explorations will not, however, release full details of these vulnerabilities until Oracle has reported and issued a fix.

So, how serious are these latest vulnerabilities? According to Paul Ducklin, head of security for Saphos in the Asia Pacific region, they are serious enough. According to Ducklin:

“[Gowdiak] implies that although it locked the office door in update 7u11, Oracle left the entrance to the building open, which he considered as good as an invitation to find another way in.”

Oracle’s run of bad news doesn’t stop there either. It has also been reported that Java vulnerability, unpatched by Oracle, was being offered for sale on an exclusive cybercrime forum.

The recently discovered Java vulnerabilities have led to widespread confusion over exactly which types of Java are at risk, worries about whether Java itself is safe, and questions over how Java-dependent enterprises should best deal with the vulnerability challenge. Oracle has been heavily criticised for failing to provide enterprises with a reliable and trusted method for updating the Java runtime-environment across a large number of managed machines. There have been general published methods of how to do this via Group Policy or Configuration Manager, but these often fail, and are not supported by Oracle.

In spite of all the recent bad press, there has been a ray of good news on the bug front according to Gowdiak: Oracle may have taken too long to issue the Java patches, but it is nevertheless secure by design in his opinion:

“Contrary to the common belief, it is not so easy to break Java,” he said in a Java security FAQ. “For a reliable, non-memory-corruption-based exploit codes, usually more than one issue needs to be combined together to achieve a full JVM sandbox compromise. This alone is both challenging and demanding as it usually requires a deep knowledge of a Java VM implementation and the tricks that can be used to break its security.”

Gowdiak has received some support from Ducklin who has also praised Oracle for taking a more aggressive stance to fixing the inherent problems within Java:

“Oracle does seem to be learning something about the sociology of patching widely distributed, consumer-targeted software like Java: patch early, patch often, don’t be in denial, and think of extra mitigations beyond what is strictly necessary.”

If you would like assistance with security reviews, penetration testing or web security solutions, please contact Krypsys on 01273 044 072 or [email protected].