Oracle is working hard to restore some faith in the security of the Java browser plug-in with a number of enhancements announced yesterday, specifically to in-house code testing, as well as policy changes regarding signed applets and certificate validation. But after a miserable year of targeted attacks abusing Java zero-days, and faulty patch updates, it would appear Oracle has a ways to go to impress the masses.
Probably the biggest security issue dragging down Java is vulnerabilities in the Java sandbox, which attackers have been particularly successful in bypassing. The Java sandbox is a sterile area where code is executed before it’s exposed to the underlying system. The idea is that the sandbox will catch malicious executables before exploits own machines.
Oracle has already instituted changes in recent security updates to prevent, for example, unsigned applets from executing by default. Users also see enhanced security warnings about potentially malicious applets and configurations that restrict what older Java versions can do. While signed applets do limit the effectiveness of some malware, it’s been proven that attackers don’t have much of an issue getting their hands on stolen digital certificates that validate malicious applets as legitimate.
“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,” said Metasploit creator HD Moore in an email to Threatpost. “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 has been critical of Java security in the past, largely because Java exploits are uncannily reliable and because they’re cross-platform, remain a hacker favorite.
Andrew Storms, director of security operations for nCircle, a Tripwire company, also gave the public announcement mixed reviews.
“It’s definitely an improvement in communication precision and that’s always a good thing,” Storms said. “On the other hand, it doesn’t do anything at all to fix the serious, ongoing systemic security issues that continue to plague the Java browser plug in.”
Oracle’s Nandini Ramani, head of the Java software development team, said that starting October, Java security updates will be part of Oracle’s quarterly Critical Patch Update schedule, giving it four scheduled annual releases, in addition to emergency updates. Ramini listed a number of security changes to Java in a blog post yesterday, including an increased usage of automated testing tools during development in the hopes of reducing the introduction of vulnerabilities into the Java code base.
Oracle has also changed the security model for signed applets.
“Previously, signing applets was only used to request increased application privileges. With this update, signing applets establishes identity of the signer, but does not necessarily grant additional privileges,” Ramani said. “As a result, it is now possible to run signed applets without allowing them to run outside the sandbox, and users can prevent the execution of any applets if they are not signed.”
Moore said this is the most significant change Oracle made.
“In the past, Oracle has suggested that all websites switch to signed applets, advice that contradicts recommendations by security experts, because signing an applet would also confer privileges to escape the sandbox,” Moore said. “In fact, signed applets are the original method of escaping the Java sandbox, and have been abused by both attackers and security auditors for the last decade. Metasploit has a module specifically for this purpose. Oracle is changing this model so that signing an applet no longer confers sandbox escape privileges. This is a good thing for security.”
Default security settings were also changed to where unsigned or self-signed applets are the norm. Admins, however, can opt out and manually OK the execution of unsigned applets. Ramani said this won’t be the case for much longer, however.
In addition, Java enables sites to check the validity of certificates through the Online Certificate Status Protocol (OCSP), but this too is not enabled by default because of potential performance issues, Ramani said. Moore said in the current security model, Java does not verify the revocation status of each certificate. Attackers with a stolen certificate can still use it until the attack is discovered. The change to OCSP and published CRLs prevent this type of attack, Moore said.
“The introduction of OCSP validation has an interesting side effect as well – an attacker can sign an applet with a custom certificate pointing to a OCSP server they host. While this won’t allow them to spoof the validity of the certificate, it will tell them whether the applet was loaded, even if it fails the check,” Moore said. “This type of information leak is present in most OCSP-enabled applications, and has been used in other file formats to track user actions (PDF, etc).”
