Additional details and code demonstrating a possible security vulnerability in Java were released this morning by a Polish security research company, bringing to a head a three-week long debate between the researcher and Oracle over whether the issue is indeed a vulnerability or an allowed behavior in Java.
Adam Gowdiak of Security Explorations has been back and forth with Oracle since Feb. 25 over the lack of a security check in a certain Java operation that when combined with another vulnerability discovered by the firm can result in a complete Java sandbox bypass.
Oracle has refused to confirm the issue is a security vulnerability and told Gowdiak that it continues to investigate. A request for comment from Oracle was not returned by the time of publication. Gowdiak said he sent Oracle detailed information on Feb. 25 about two vulnerabilities he calls Issue 54 and 55, along with source and binaries for proof of concept code. Oracle confirmed Issue 55 as a vulnerability, but said 54 is an “allowed behavior.”
“Security Explorations believes that three weeks (from Feb. 25 to March 18) constitutes enough time for a major software vendor to be able to deliver a final confirmation or denial of a reported security issue,” he wrote in a PDF linked to from Full Disclosure.
He told Threatpost today via email that while he has provided details on issue 54 today, a working exploit cannot be built without details on the second vulnerability.
The crux of Issue 54, he said, lies in the fact that certain MethodHandle lookups do not invoke the built-in security manager in Java. In the code sample he provided today, he demonstrated where a call to the security manager is not made in a private resolveVirtual method, enabling him to gain access to the protected Method Handle of java.lang.ClassLoader class. Gowdiak said this API is called internally by the Java virtual machine at the time of Class file parsing. Access to same object is not allowed when a public API is used.
“The dispute between Oracle and us is whether obtaining access to the defineClass Method Handle we get access to and use in our exploit code should be treated as a bug or not,” Gowdiak said.
“One could visualize the whole situation as following: Imagine having an office with a front door (the public Java API) and an ’employees only’ door (an internal, private JVM call),” he explained. “Getting to the item that’s in the office is prohibited for untrusted visitors (Java code), however when the ’employees only’ door is used, that access can be obtained.”
Oracle told Gowdiak in one of their exchanges that “obtaining a method handle for a protected method from a superclass is allowed behavior,” something the researcher disputes, and said he proved with another code sample demonstrating where the security manager denied access to a protected member via a public API.
“Oracle had two different arguments so far,” Gowdiak said. “The company initially claimed that it’s OK to get access to protected members of Java classes from their subclasses. Later on, the company started to back up its claims with the use of the JVM spec.”
Oracle rushed an emergency Java update, Java 7u17, to patch zero-day vulnerabilities being exploited by the McRAT remote access Trojan affecting Java 6u41 and Java 7u15. The next scheduled Java security update is scheduled for April 16, yet the platform and browser plug-in has been updated five times already this year. Expect additional updates on the heels of today’s disclosure and five more vulnerabilities found by Security Explorations and reported to Oracle on March 4. The handful of flaws was related to the Java Reflection API and would also enable a sandbox bypass.
