Optimism and praise followed last week’s Java critical patch update. Oracle not only patched 42 vulnerabilities in the Java browser plug-in, but also added new code-signing restrictions and new prompts warning users when applets are potentially malicious. It took less than a week, however, to deflate any good will toward Java that resulted.
Noted Java bug hunter Adam Gowdiak, founder and CEO of Security Explorations of Poland, said this week that he reported to Oracle a new Reflection API vulnerability that affects all Java versions, including 7u21 released last Tuesday.
“It can be used to achieve a complete Java security sandbox bypass on a target system,” Gowdiak wrote on the Full Disclosure mailing list on Monday. “Successful exploitation in a Web browser scenario requires proper user interaction (a user needs to accept the risk of executing a potentially malicious Java application when a security warning window is displayed).”
Attackers can exploit this vulnerability to achieve a complete Java security sandbox escape, Gowdiak said, adding that he also send proof-of-concept code to Oracle demonstrating an exploit. Gowdiak, who first reported vulnerabilities in the Reflection API a year ago, also said that this vulnerability is present in the server versions of the Java Runtime Environment, as well as in the JRE Plugin and JDK software.
“It’s been a year since then and to our true surprise, we were still able to discover one of the simplest and most powerful instances of Java Reflection API-based vulnerabilities,” Gowdiak said. “It looks like Oracle was primarily focused on hunting down potentially dangerous Reflection API calls in the ‘allowed’ class space. If so, no surprise [this issue] was overlooked.”
Gowdiak identified four Java components and APIs that are risk for exploit: Sun Microsystems’ implementation of the XSLT interpreter; Long Term Persistence of JavaBeans Components; RMI and LDAP (RFC 2713); and many SQL implementations.
“These are the APIs and Java components that could be potentially used as execution vectors for untrusted Java code in other than web browser environments,” he told Threatpost via email. “In other words, they have the potential to be abused for the exploitation of Java SE flaws.”
Last week’s Oracle patch update repaired many issues plaguing the platform. Of the 42 vulnerabilities patched in the update, all but three were remotely exploitable. A number of Java zero-day vulnerabilities and exploits have been the center of watering hole attacks and other high-profile website hacks.
The update also now requires any applets that execute at runtime on the browser be signed with a trusted certificate, and that all code will prompt the user for approval. The level of user interaction required depends on the potential risk involved, Oracle said. Oracle has color coded its user prompts; blue for apps signed by a trusted certificate, and yellow indicating an untrusted or expired certificate. Red text accompanies high-risk warnings that an applet could be a security risk.
“We are not sure if these warnings will help the platform,” Gowdiak said. “Java was supposed to provide a safe execution environment for untrusted, potentially harmful code. A dialog prompt warning a user about a security risk prior to the execution of an untrusted application basically denounces one of the main advantages of the platform: its security.”
Oracle also removed the low security settings in the Java Control Panel; users will no longer be able to opt out of the security features built into Java.
“The platform will not deny the execution of Java applications, however in high-risk scenarios the user is provided an opportunity to abort execution if they choose,” Oracle said in its advisory last week. “Future update releases may include additional changes to restrict unsafe behaviors like unsigned and self-signed applications.”
