Prompted by Oracle Rejection, Researcher Finds Five New Java Sandbox Vulnerabilities

Giving a prolific bug hunter an excuse to go poking deeper into a potential security issue generally doesn’t end well or the vendor in question—in this case Oracle. Polish security firm Security Explorations, noteworthy for its Java security research, said today it reported five new vulnerabilities in Java SE 7 to Oracle. If combined, researcher Adam Gowdiak said, they can be used to gain a complete bypass of the Java sandbox.

Java SandboxGiving a prolific bug hunter an excuse to go poking deeper into a potential security issue generally doesn’t end well or the vendor in question—in this case Oracle. Polish security firm Security Explorations, noteworthy for its Java security research, said today it reported five new vulnerabilities in Java SE 7 to Oracle. If combined, researcher Adam Gowdiak said, they can be used to gain a complete bypass of the Java sandbox.

The deeper look stemmed from a recent submission the company made to Oracle on Feb. 25 of two vulnerabilities that when used in conjunction could also bypass the sandbox.  Gowdiak said Oracle dismissed one of the issues he reported, which he labels Issue 54, and called it “allowed behavior,” rather than a vulnerability. It confirmed the other.

“We confirmed that company’s initial judgment of Issue 54 as the ‘allowed behavior’ contradicts both Java SE documentation as well as existing security checks in code,” he said. “It looks Oracle needs to either start treating Issue 54 as a vulnerability or change the docs and relax some of the existing security checks.”

Gowdiak said his company provided Oracle with code samples proving the “allowed behavior” is not allowed in Java SE.

“The codes we delivered to Oracle trigger real security exceptions in a response to the attempt to gain same access as the one abused by Issue 54,” he told Threatpost. “We’ve also found evidence in Oracle’s own Java SE docs that contradicts company’s claims.”

This latest twist just compounds a miserable year for Java security; last week another attack was reported that targeted Java 6u41 through Java 7u15.

Gowdiak would not provide many details on the five vulnerabilities reported today, other than to say four of the five problems lie in a vulnerability in the Reflection API.

“The attack breaks a couple of security checks introduced to Java SE by Oracle over the recent months (Issues 57 and 58). It also exploits code fragments that were missing proper security checks corresponding to the very mirror code (Issue 59 and 60),” Gowdiak wrote on the Full Disclosure List. “Finally, it demonstrates a difference between the JVM specification and its implementation (Issue 56).”

Gowdiak said his company did not check whether the flaws impact Java 6, and added that Security Explorations may disclose details should Oracle not treat Issue 54 as a vulnerability.

“We disagree with Oracle’s assessment regarding Issue 54. There is a mirror case corresponding to Issue 54 that leads to access denied condition and a security exception. That alone seems to be enough to contradict the ‘allowed behavior’ claim by the company (is it possible to claim a non-security vulnerability when access is denied for a public API, but allowed for some private code path?),” Gowdiak said. “If Oracle sticks to their assessment we’ll have no choice than to publish details of Issue 54.”

Suggested articles

Broken IBM Java Patch Prompts Another Disclosure

Current versions of IBM SDK 7 and SDK 8 remain vulnerable to a 2013 Java vulnerability. Security Explorations discovered the original patch is broken and disclosed details on the flaw and a proof-of-concept exploit.