Why would a software company require developers to sign code, thereby ensuring a modicum of trust—but not security—and then shatter that trust by allowing signed applets to bypass their own application sandbox?
Welcome to the world of Oracle and Java, where a once healthy programming language has been reduced to rubble. Not only are security researchers, ferocious cybercriminals and nation-state hackers feasting on vulnerable code and broken patches, but also longtime developers are losing faith.
“Bottom line, I’m looking for a new language, probably HTML5,” said Jerry Jongerius, a Java developer since 1996 and owner of Java resource Duckware.com. Jongerius has spent the past week railing on his personal blog against Java’s many security issues and what he says are Oracle’s failed attempts at improving Java security. His frustration is palpable, especially since the latest Java update, which requires code-signing, broke applets he’s had up and running for more than 15 years.
In April, Oracle instituted a number of changes starting with Java 7u21. The new update introduced prompts warning users that an unsigned applet could potentially harm the user’s computer. This came months after Oracle changed Java’s default security settings from medium to high, essentially preventing unsigned applets from executing automatically, requiring instead a user to allow the applet to proceed. Developers must now sign their applets with a certificate from a trusted Certificate Authority.
However, research done since by Jongerius and others such as Will Dormann of CERT at Carnegie Mellon University’s Software Engineering Institute, indicate that the Java sandbox’s wounds are self-inflicted because signed applets bypass the sandbox and have full access to the rest of the host computer.
“The sandbox is a huge problem for Oracle,” Jongerius told Threatpost. “Everyone is breaking in. Their solution is to code-sign and get out of the sandbox. But then, you have full permission to the machine. It doesn’t make sesnse.”
Dormann wrote in an April blogpost that Oracle “conflates” authentication and authorization by allowing signed applets to gain automatic full privileges on a machine.
“Right now, if an attacker wants to repurpose a Java applet, it would need to be a signed applet. But what about Oracle’s vision of a Java future where every Java applet is signed? What this vision means is that every Java applet, which would be signed, would also now be in a state where it could be repurposed because it is now no longer restricted by the sandbox,” Dormann said. “A poorly designed sandboxed Java applet can’t do much of anything. However, a poorly designed signed Java applet can do pretty much anything that native code can.”
And just as bad are the bugs Jongerius uncovered once he started digging into the issues his sites were having. He notes that even with code-signed applets, the Java VM still presents the user with a dialog box information about the applet. He revealed that the name of the application as well as the JAR file name presented inside the security dialog box can be renamed.
“Once a Publisher signs a JAR file, there is NO legitimate reason (other than hacker activity) for Oracle to allow the JAR to be renamed to something else,” Jongerius wrote.
He also wrote that Java will block applets that request to be run in the sandbox, adding that instead the default condition should be to sandbox applets regardless of whether they’re signed. He adds that developers should ask for full access in signed code, and not be granted access by signing code as is the current state.
In the meantime, users are presented with applets he says are confusing and could shy people away from his sites and tools.
“Oracle is absolutely killing off applets. You cannot go to a website and have a popup come up and expect a user to run it,” Jongerius said. “I’ve had a panorama viewer that’s done well over the years and now users are getting a popup in red that says if they run it, it may ham their computer. It’s just gone too far; it’s killing my software.”
