Oracle has faced an uphill battle when it comes to Java and security. As soon as a series of fixes are released, someone somewhere (usually a researcher) discovers another flaw, and the cycle begins anew – and it’s painful. Now, Oracle plans to fix that by heavily investing in Java’s security.
Nandini Ramani, Oracle’s lead for the software development team that’s building the Java platform, wrote in a blog post on Friday that the company is seeing gains from their investments in the platform’s security and that such investments will continue.
“[The] procedural and technical changes implemented throughout Java development have enabled the organization to make improvements affecting both the Critical Patch Update program (scheduled release of a greater number of security fixes) and the Security Alert program (faster release of unscheduled security fixes in response to 0-days or particularly severe vulnerabilities),” Ramani wrote.
One such change is the quarterly release of Java fixes under the Oracle Critical Patch Update schedule. While out-of-band fixes can be released if the need is great enough, the plan moving forward, if current trends remain the same, will see Oracle releasing Java updates that address a large number of issues every three months.
In total, Oracle has released 97 security fixes this year; showing a 67 percent gain over 2012’s numbers. While this can be seen as a gain in the way Oracle is dealing with Java’s security issues, patching them faster and in larger numbers – it is also proof of just how bad the problem is.
Java is broken, and Oracle knows it. The platform earned a black mark earlier this year when the Department of Homeland Security (via U.S. CERT) advised the public to stop using Java. Then to make matters worse, Facebook implemented policy changes to disable Java within their environment after a security incident was traced directly to vulnerabilities in the platform.
Another change to Java announced by Oracle relates to how signed applets are handled. With the release of JDK Update 21, the security of signed applets was changed so that signed applets no longer have to run outside of the sandbox. Before this change, signed applets were used by criminals, researchers, and auditors to escape the sandbox.
Oracle has also announced changes to certificate validation.
“In the current security model, Java will not verify the revocation status of each certificate, making it easy for an attacker with a stolen certificate to continue using it after the attack has been discovered,” Rapid7’s Chief Research Officer, HD Moore, said in a statement.”This change will force revocation checks using published CRL and the Online Certificate Status Protocol (OCSP), incurring a performance hit, but preventing this type of attack in the future.”
Taken as a whole, Moore noted, the investments described by Oracle and the changes to the way security is addressed within the Java platform are a good thing.
“[But] these changes don’t solve the underlying problem with the Java sandbox itself,” he said. “Until Oracle implements process-level sandboxing, such as that used by Adobe Reader and Google Chrome, a malicious applet with a valid signature can still abuse JRE security flaws to escape the sandbox and compromise the system. Obtaining a code signing certificate has not been a barrier for malware in the past and there is little chance it will become one in the future.”
None of the changes announced by Oracle will amount to a silver bullet when it comes to fixing Java’s security problem. But even healthy skeptics have to admit it is at least a step in the right direction.
The standout issue within all of these changes is the quarterly patch release. Given the volume of reported vulnerabilities in the last 18 months, compared to the number of fixes released, it seems a quarterly plan would be too slow and unpractical.
