For a long time, I was among the voices who called for computer users to disable Java from their systems. The security risks in Java were far too great, I and others said, and outweighed any benefits to keeping it on your computer. In addition, Oracle wasn’t doing a good job at fixing vulnerabilities and offering patches in a timely manner.
It now appears that Oracle is making an effort to regain public trust in Java. Last week, Java’s software development team released a blog post that outlines the “security-worthiness” of Java and what security changes Oracle is making. The company announced that there will be four regular security releases this year, as well as emergency out-of-band fixes when needed. It has expanded automated security testing tools. And, perhaps most importantly, Oracle addresses three long-standing issues with the Java security model. According to the blog, they are:
(1) The security model for signed applets was changed. With this update, signing applets establishes identity of the signer, but does not necessarily grant additional privileges.
(2) The default plug-in security settings were changed to further discourage the execution of unsigned or self-signed applets.
(3) While Java provides the ability to check the validity of signed certificates through Certificate Revocation Lists (CRLs) or Online Certificate Status Protocol (OCSP) calls before the execution of signed applets, the feature is not enabled by default because of a potential negative performance impact. Oracle is making improvements to standardized revocation services to enable them by default in a future release.
Any step to improving security is a good thing. Especially for a company that has been as bashed as Oracle on security (or lack thereof) issues. However, is it a big enough step? Rapid7’s Chief Research Officer, HD Moore, doesn’t seem to think so. He told me in an email:
Taken as a whole, this is good thing for Java, but these changes don’t solve the underlying problem with the Java sandbox itself. 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.
Moore also thinks there are problems with the OCSP updates, as well: An attacker can sign an applet with a custom certificate pointing to an OCSP server they host. While this won’t allow them to spoof the validity of the certificate, Moore pointed out, it will tell them whether the applet was loaded, even if it fails the check.
Oracle has a long way to go to build trust in Java – or convince users who have dropped it to go back. Time will tell if the efforts work, but my own feeling is that these changes come way too late.
