Update For the second time in two weeks, researchers have discovered a three-year-old broken patch for a vulnerability in IBM’s Java SDK implementation.
The flaw allows for an attacker to execute code outside the Java sandbox, and still affects current versions of IBM SDK, 7 and 8, released in January.
Details of the vulnerability and proof-of-concept code were disclosed by Polish consultancy Security Explorations. The organization announced, on March 7, a change in internal policy whereby the company will disclose bugs if the vendor’s patch is broken or incomplete.
On April 4, Security Explorations disclosed a separate flaw in IBM SDK 7/8 and said it was the sixth such broken fix from IBM.
Yesterday’s disclosure centered around CVE-2013-5456, which Security Explorations privately reported in October 2013 and was patched in a November 2013 release of IBM Java. The patch failed, according to Security Explorations.
In a report, the researchers said IBM had not addressed the root cause of the vulnerability, and instead, just focused on the proof-of-concept exploit submitted with the original bug report. From the Security Explorations disclosure:
“Issue 70 had its origin in com.ibm.rmi.io.SunSerializableFactory class. It was caused by insecure implementation of a deserialization process of arbitrary classes. More specifically, during this process, a constructor of the first non-serializable superclass was called inside AccessController’s doPrivileged block. This condition could be successfully exploited to create custom and fully functional java.lang.ClassLoader objects. As a result, a complete Java security sandbox escape could be gained.”
IBM said in a statement: “IBM is aware of the vulnerability and is working to address the issue.”
CEO Adam Gowdiak said IBM failed to introduce any security checks into the code.
“In general, one should not call superclass’ constructors of arbitrary Serializable classes inside a privileged code block,” Gowdiak told Threatpost. “If one really needs to do it, such an operation should be preceded with a proper permission check if a code is executed in a security sandbox.”
Sandbox bypass flaws have plagued Java for years, and still do despite Oracle’s attempts to lock down the beleaguered platform by implementing measures such as denying unsigned applets from automatically executing.
“There were not many changes/security mitigations introduced to Java at the core (VM) level that could prevent this,” Gowdiak said. “Over the recent years, the focus was put on preventing automatic (silent) execution of Java applets than on making the platform more secure/harder to exploit.”
Gowdiak said this vulnerability could be exploited via a browser if IBM Java is configured as a plugin. He noted that some IBM products such as Notes, Domino, Websphere and Tivoli also rely on implementations of IBM Java.
“This makes the potential for both web-based (via a web browser) and server-based attacks (through web hosting / cloud applications),” Gowdiak said. “But, we haven’t verified any of the above attack vectors (our POC codes are executed from a command line).”
In the meantime, Security Explorations continues to put its new policy through its early paces. Already, it has disclosed details on an old Java bug that was inadequately addressed by Oracle, the company said, in addition to the recent IBM disclosures.
Gowdiak said it’s too early to judge the effectiveness of the new policy. “We hope this new policy enforces higher quality patches and better work from software vendors,” he said. “That alone will be a positive effect, even if it is limited to the issues we report.”
This article was updated on April 13 with a comment from IBM.
