Posted on by Vulnerability Analysisin
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:
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:
META-INF/MANIFEST.MFfile does not have the
Permissionsproperty that you wish to enforce, you may wish to verify the structure of the manifest file and try again.
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.
Below are dialogs for Case 2 above:
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.
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.