Researcher Develops Patch for Java Zero-Day, Puts Pressure on Oracle to Deliver its Fix

A security researcher has submitted to Oracle a patch he said took him 30 minutes to produce that would repair a zero-day vulnerability currently exposed in Java SE. He hopes his actions will spur Oracle to issue an out-of-band patch for the sandbox-escape vulnerability, rather than wait for the February 2013 Critical Patch Update as Oracle earlier said it would.

Oracle bugA security researcher has submitted to Oracle a patch he said took him 30 minutes to produce that would repair a zero-day vulnerability currently exposed in Java SE. He hopes his actions will spur Oracle to issue an out-of-band patch for the sandbox-escape vulnerability, rather than wait for the February 2013 Critical Patch Update as Oracle earlier said it would.

Adam Gowdiak of Polish security consultancy Security Explorations reported the vulnerability to Oracle on Sept. 25, as well as proof-of-concept exploit code his team produced. The vulnerability is present in Java versions 5, 6 and 7 and would allow an attacker to remotely control an infected machine once a user landed on a malicious website hosting the exploit.

Gowdiak said his proof-of-concept exploit was successfully used against a fully patched Windows 7 machine using Firefox 15.0.1, Chrome 21, IE 9, Opera 12, and Safari 5.1.7.

Gowdiak said he’s been in contact with Oracle about his research and more specifically why Oracle told him they’d decided not to patch the flaw for another four months. Gowdiak said Oracle told him it was in the final stages of testing the patches delivered in the latest CPU last week and that it was too late to include a fix for the sandbox escape.

“In general, Oracle’s response was that their Critical Patch Updates go through an extensive integration testing with other products such as JRockit, Weblogic Server, and E-Business Suite and that any delay [to the October] Java SE CPU would result in a delay to deliver 139 fixes for applications integrating Java SE,” Gowdiak wrote today on the Full Disclosure mailing list.

“We might understand all of the above, but still, does it really take more than four months to fix a critical issue in Java?” Gowdiak asked.

Escaping the sandbox environment, where untrusted Java code is supposed to be run and executed before allowing it access to the host machine, could enable an attacker to remotely run malware, view, change or delete data with the user’s privileges. Gowdiak said an attacker’s website could host a malicious Java applet or a banner ad could deliver malware to a vulnerable machine.

Oracle did patch 30 Java vulnerabilities, all but one remotely exploitable and 10 of them were given the highest criticality score on the CVSS matrix. Oracle also released patches for 109 vulnerabilities on a number of platforms including Oracle Database Server, Fusion Middleware, Sun products and MySQL Server, among others.

Gowdiak said his team decided to build a patch on their own, which they did. He did not provide any details publicly, but said a fix could be implemented within 30 minutes (it took him 26 minutes) and only 25 characters needed to be either removed or added in source code to implement the fix. He also said the fix did not seem to require any integration tests with other Oracle software.

“Code logic is not changed at all,” Gowdiak said. “Minor changes are applied to the code, none of them influence what could be described as an externally visible scope affected third-party applications.”

He said he provided Oracle the results of his work last Friday.

“We hope our quick experiment sufficiently challenges the company and that it leads to the verification of Oracle’s stance, especially the one relying on a need for four additional months to implement and release a security update for a critical security issue in Java, which we believe (and are hopefully correct with respect to the analysis conducted) can be addressed within less than 30 minutes,” he said.

Suggested articles