Don't Sign that Applet!
Hi, it's Will. I've recently been looking into the state of signed Java applet security. This investigation was triggered by the Oracle blog post IMP: Your Java Applets and Web Start Applications Should Be Signed, which as the title implies, suggests that all Java developers sign their applets, regardless of the privileges required. In this blog entry, I explain why this practice is a bad idea.
I've blogged about the security aspects of signed Java applets before in Signed Java Applet Security: Worse than ActiveX? In that blog post, I explained how signed Java applets are not restricted by the Java sandbox and how the dialogs presented to the user are both confusing and include dangerous default options. Another relevant blog post is Signed Java and Cisco AnyConnect. The motivating factor for that post was to describe what happens now that a vulnerability has been discovered in the Cisco AnyConnect signed Java applet. In particular, I explained how an attacker could repurpose the vulnerable applet to achieve the goal of remote code execution.
You might be putting the pieces together already:
- Oracle says that all Java applets should be signed.
- Signed Java applets run outside of the Java sandbox.
- Some Java applets have vulnerabilities.
In the case of an unsigned Java applet, in the absence of a vulnerability in the Java Runtime Environment (JRE) sandbox, vulnerabilities in the applet itself aren't really interesting; that is, if the concept of a vulnerability in a sandboxed applet even makes sense. 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. 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.
How did Oracle get into this situation? It all goes back to an architectural weakness that has been present in Java since the concept of a signed applet was introduced. Java conflates authentication ("Who wrote this code?") with authorization ("What is this code allowed to do?"). When you sign an applet, it gets privileges automatically.
Historically, I believe that it has been well understood that a signed applet is privileged. Or at least, I hope that people understood this. However, Oracle is not taking this aspect into consideration with their guidance to developers to sign all of their applets. Until the aspects of authorization and authentication are properly separated, it will not be safe to sign all applets.
A Java applet can have an internal JNLP file that specifies the privileges requested by the applet. If no privileges are requested, then the applet is sandboxed. But this situation is only the case if the applet is launched from a JNLP file. If the applet is launched using an
<embed> HTML tag, the applet is given full privileges by default. That's right. JNLP gives sandbox privileges by default, and HTML tags give full privileges by default. We verified that this is the case with Java versions up to and including 7u21.
In other words, there appears to be no way that a Java applet can be signed and specify that it is only to be executed in a sandbox. The current Java version does not enforce privileges in a way that allows this combination to happen. This challenge is one of the reasons we wrote The CERT Oracle Secure Coding Standard for Java rule ENV00-J. Do not sign code that performs only unprivileged operations. Heck, even Oracle's own guidance states: "For applets and JNLP applications the best approach is often to leave the jar files unsigned."
Until this situation is fixed, Java developers should not sign applets that do not need privileges!
Even once Oracle fixes the JRE to enforce inherently signed-but-sandboxed Java applets, the situation for the end user still leaves something to be desired. With Java 7u21, Oracle has updated the security dialogs that are presented to the user. In particular, consider the dialog presented before a signed applet runs:
From a security perspective, the difference between a privileged applet and a sandboxed applet is major. But what's the difference in the dialog presented to the user?
Privileged: The application will run with unrestricted access which may put your computer and personal information at risk.
Sandboxed: The application will run with restricted access that is intended to protect your computer and personal information.
How thoroughly do most home users read text in dialog boxes that are presented to them? Given that the other aspects of the dialog are the same, is the difference between restricted and unrestricted obvious enough to let the user know the impact of the decision they are about to make?
As we have mentioned before, if you don't need Java in your web browser, turn it off. If you don't know if you need Java in your web browser, turn it off anyway and see what breaks. You might find that it doesn't affect you at all.
Update: September 24, 2013
Oracle has introduced features in Java 7u25 that help to prevent repurposing. See the CERT/CC blog post Signed Java Applet Security Improvements for more details.