For all of Oracle’s bluster last Thursday about Java security enhancements, next to nothing was said about the real issue behind months of misery this year: the Java sandbox.
Oracle broke its radio silence late last week with an out-of-the-blue blogpost full of promises about getting Java right. Already this year, Oracle has promised to delay Java 8 in order to get the platform’s security story in line, it has adjusted default security settings to maximum levels on new versions of Java, and delivered shiny new dialog boxes warning users when a foul applet might be afoot.
Yet the heralded Java sandbox remains a shooting gallery for hackers. And not just for run-of-the-mill identity thieves and fraud artists. Nation-state supported hacking teams have taken dead aim and connected with nasty sandbox escapes that enable surveillance and espionage malware to be placed on endpoints running Java; attacks that have breathed life into the concept of watering hole attacks.
Experts have not been kind to Oracle, urging both business and consumer computer users to disable Java, providing not only stern warnings, but detailed instructions on how to do so. Most users wouldn’t miss Java as part of their day-to-day browsing, but some home-grown enterprise Web applications are Java-based, rendering suggestions to abandon the platform moot.
The sandbox is supposed to be a safe haven where shaky code is executed before it infects the underlying system. When you put up barriers to get over a wall, there’s always someone in the bunch who figures out how to get under the wall. And that’s what’s happened on numerous occasions. Security researchers and hackers alike have found vulnerabilities in Java that allow for exploits to be carved out that bypass the sandbox protection innate to Java.
Adam Gowdiak of Security Explorations in Poland has made great sport of Java sandbox bypasses this year, using in particular a number of Reflection API attacks to circumvent the sandbox’s quarantine.
“The issues are related to the design and implementation of Java security model. Certain APIs such as Reflection API do not fit that model very well. This API can be easily abused if not properly implemented. As a result, some security checks can be skipped and access to restricted classes or methods can be gained,” Gowdiak told Threatpost in an email. “Reflection API was the primary victim when it comes to recent year’s sandbox bypass exploits. Although the problem is known to the vendor since 2005, dozens of insecure Reflection API calls were introduced into Java SE 7. That alone indicates poor secure code development practices at Oracle.”
Oracle’s Java software development lead Nandini Ramani wrote the blogpost last Thursday and indicated that Java programmers at Oracle will have to undergo their own version of Microsoft’s Trustworthy Computing.
“For example, the Java development organization had to adopt Oracle’s Security Fixing Policies, which among other things mandate that issues must be resolved in priority order and addressed within a certain period of time,” Ramani wrote. “As a result of adopting these stricter procedures, as well as increasing investments in Java overall by Oracle, Java development significantly accelerated the production of security fixes.”
Oddly enough, Ramani’s metric for success was to illustrate how the number of patches has increased exponentially in Oracle’s Critical Patch Updates for the Java SE, from 14 security patches in February 2012 to 97 already in the first half of 2013. Ramani said that Oracle is expanding the use of its code-testing gear to reach deep into Java code.
“The Java team has engaged with Oracle’s primary source code analysis provider to enhance the ability of the tool to work in the Java environment. The team has also developed sophisticated analysis tools to weed out certain types of vulnerabilities (e.g., fuzzing tools),” Ramani said.
Gowdiak was not particularly taken with Oracle’s announcement and said there wasn’t much to see.
“We don’t see anything in Oracle’s announcement that would indicate that some serious effort will be undertaken by the company to improve quality and security of Java code and the sandbox itself,” Gowdiak said. “Company’s efforts are aimed primarily at discouraging malware writers from launching attacks by the means of a Java Plugin. The goal should be to make it far more difficult to break Java security sandbox. The problem is not with Java in the browser as the company claims, but with the quality and security of the code under Oracle’s control.”
HD Moore, Metasploit creator and CSO at vulnerability management company Rapid7, applauded a number of changes Oracle made to certificate validation and requirements around the signing of applets but too cautions that Oracle is addressing symptoms and not curing the disease.
“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,” Moore said to Threatpost via email. “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.”
