Hi folks, it's Will Dormann. A few months ago I published a blog entry called Don't Sign that Applet! that outlined some concerns with Oracle's guidance that all Java applets should be signed. The problem is that with Java versions prior to 7u25, there is nothing that prevents a signed applet from being repurposed by an attacker to execute with full privileges. As it turns out, Java 7u25 introduced features to prevent a Java applet from being repurposed. Thanks to CERT/CC blog reader Rob Whelan for pointing this out! There are some potential pitfalls when using this feature, however.

Starting with Java 7u25, a developer can specify two new attributes in a signed Java applet manifest file: Permissions and Codebase.

Permissions

With Java versions prior to 7u25, there is no way for an applet to internally specify that it must only be executed in a sandbox. If a signed applet is launched from an <applet>, <object>, or <embed> HTML tag, then the applet runs with full privileges. The Permissions manifest attribute introduced with Java 7u25 addresses this problem. In my testing, there are a few potential pitfalls when using this manifest attribute:

1. The manifest file must end in a newline or carriage return, or the JDK may silently ignore the last item of the manifest. If the Permissions attribute is specified on the last line of the manifest without a newline or carriage return, then that attribute will be ignored when the jar file is created. This behavior is documented by Oracle. One way to verify that you are affected by this issue is to manually unzip the jar file. If the META-INF/MANIFEST.MF file does not have the Permissions property that you wish to enforce, you may wish to verify the structure of the manifest file and try again.
2. If an applet specifies that it must be sandboxed, any HTML document that uses the applet must also specify permissions="sandbox" in a manner compatible with the way that the applet is invoked. Otherwise, the JRE may display error dialogs similar to the images below and refuse to execute the applet.
3. JRE 7u25 or newer must be used on the client system for the permissions to be enforced.

Below are dialogs for Case 2 above:

Codebase

The Codebase manifest attribute introduced with Java 7u25 can be used to restrict the code base of the jar to specific domains. This attribute can help to prevent the aspect of repurposing where an attacker hosts his own copy of an applet. This functionality is similar to the Site-Lock template that Microsoft provided for ActiveX developers.

Conclusion

By properly using both the Permissions and Codebase manifest attributes, a Java developer should be able to safely sign his or her applets if clients are using Java 7u25 or newer. Clients with older Java versions will still be vulnerable to applet repurposing.