Researchers from Security Explorations – the ones who reported the security holes leveraged by the new Java zero-day exploit to Oracle – say that the vulnerabilities will surely be addressed in the upcoming CPU.
The monthly status report they received from Oracle on August 23 confirmed that the issues used by the attack code have already been addressed.
According to the experts, there are two main vulnerabilities used for the exploit. One of them – codenamed “Issue 11” and reported to Oracle back in April 2012 – is caused by the fact that it is possible to obtain references to restricted classes, such as the ones from the
sun.* package.
“The weakness has its origin in
com.sun.beans.finder.ClassFinder class and its
findClass method. The bug is caused by insecure usage of reflective
forName call of
java.lang.Class class,” Adam Gowdiak, CEO of Security Explorations, told Softpedia via email.
“In our report describing Issue 11 we demonstrated a successful loading of a ‘sun.awt.SunToolkit’ class by the means of a
findClass method of
ClassFinder class. We however did associate this behavior with a slightly different cause.”
The second security hole – Issue 16 – was also reported by the firm to Oracle at around the same period.
“The second vulnerability relies on the possibility to obtain references to methods of restricted classes. It has its origin in
findMethod method of
com.sun.beans.finder.MethodFinder class. The bug is caused by insecure usage of reflective
getMethod call of
java.lang.Class class,” Gowdiak added.
“Insecure
ClassFinder and
MethodFinder classes were introduced in Java 7. Among other things, this has led to the modification of
java.beans.Statement class implementation. Java 6 implementation of the aforementioned class seems to be more secure as it relies on a
ReflectionUtils class introduced at the time of fixing the vulnerabilities reported to Sun Microsystems back in 2005.”
Just as interesting as the vulnerabilities is the actual exploit vector. It relies on the
sun.awt.Suntoolkit class and the ability to call its
getField method, which allows the attacker to obtain privileged references to the private fields of arbitrary classes. Similar to the vulnerabilities, the exploit code was also disclosed to Oracle back in April.
“We demonstrated full JVM sandbox bypass by abusing SunToolkit class implementation, but in a different way than it is done in a circulating code. Again, Java 6 implementation of SunToolkit class seems to be more secure as its
getField method is defined to be private (it is public in Java 7),” the expert explained.
“The reported attack code will not work in Java 6 environment for the reasons described above. Although, Java 7 adoption might not be high yet, with the release of Java SE 7 Update 4, Java SE 7 runtime is the default JRE.”
On the bright side, the experts are confident that if Oracle fixes the problems caused by the vulnerable
ClassFinder and
MethodFinder classes, the issue will be addressed. In the meantime, they advise users to uninstall Java from the browser, or remove it completely if it's not needed.
Security Explorations will release a technical paper on the matter once the issue is addressed by Oracle.
Find us on Google+
