Java applet security model incompatibility between OS X JREs 6 and 7: any workaround?

Question

I'm the author of Wordle, one of the few surviving Java applets in the wild.

Recently, I received user reports of warnings that my (signed) applet would soon be blackballed by the JRE because it did not explicitly specify a "Permissions" attribute in its manifest. So, now the MANIFEST.MF correctly specifies

    Permissions: sandbox

and the <applet> tag includes the magical

    <param name="permissions" value="sandbox" />

param, as documented.

Now, folks who have bent over backwards to install the OS X JRE 7 can run Wordle with no difficulty, but folks (like many school IT admins) stuck on JRE 6 cannot run the applet at all; they get

java.lang.SecurityException: JAR manifest requested to run in sandbox only:
http://wordle.appspot.com/j/v1390/wordle.jar
    at com.sun.deploy.security.DeployManifestChecker.verify(DeployManifestChecker.java:106)
    at com.sun.deploy.security.DeployManifestChecker.verify(DeployManifestChecker.java:84)
    at com.sun.deploy.security.TrustDecider.isAllPermissionGranted(TrustDecider.java:319)
    at com.sun.deploy.security.TrustDecider.isAllPermissionGranted(TrustDecider.java:280)
    at com.sun.deploy.security.TrustDecider.isAllPermissionGranted(TrustDecider.java:270)
    at sun.plugin2.applet.Plugin2Manager.isAppletSigned(Plugin2Manager.java:3289)
    at sun.plugin2.applet.Plugin2Manager.createApplet(Plugin2Manager.java:3207)
    at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Plugin2Manager.java:1536)
    at java.lang.Thread.run(Thread.java:695)`

The symptom suggests that the Java 6 plugin assumes that the signed applet should run in all-permissions mode, and thinks that the request for sandbox in the manifest is an error. It ignores, in other words, the permissions param in the applet tag.

Does anyone know of any way for me to help my users other than setting the applet to run in all-permissions mode? I'd prefer to stay sandboxed, both because I don't want people to be afraid to use Wordle, and because I don't want to create an attack surface.

Occident

Just an idea, maybe it is possible to check the java version of the client, and deliver the appropriate version of your program (with permissions set accordingly). – Addlepated

I'm hitting the same problem with my applets -- Currently I'm testing to see if variations on the possible manifest attributes can help at all. Currently (getting this same error) I have: Permissions: sandbox Application-Name: eMusicTheory drill Codebase: *.emusictheory.com Sealed: true I'm tinkering with Trusted-Only: true and other tweaks, but I suspect this bug can't be worked around, and I'll be forced to serve the applet with full permissions for pre-10.6.8 OS X. – Starfish

Another idea -- instead of putting the permissions param in the applet tag (as we both are, I believe), what about launching the applet with a JNLP file? This might take a sufficiently different path through the plugin code that Java it will bypass the broken code. – Starfish

I now have two JARs: one with all-permissions in the manifest, and one with sandbox. I detect the plugin version using Oracle's deploy.js, and load the all-permissions version when the plugin is not 1.7 or better. I hate doing it, but the "it doesn't work" emails have ceased. – Occident

Doesn't deploy.js cause extra plugin warnings from Firefox, though? I stopped using it because Firefox doesn't trust the object it embeds to detect the Java version. I'm in the middle of setting up your solution, but just checking the OS version (if I can do that reliably across browsers...). – Starfish

As far as I can tell that's not correct. See java.com/js/deployJava.txt for source, where it appears to be using plugin detection via mime types. – Occident

I'm afraid they haven't yet updated deployJava.js to remove the dependency on the Java Deployment Toolkit plugin. See the references to the "deployJavaPlugin" object in various places in the script you referenced. Or: open a Wordle page in Firefox and scroll to the bottom of the page -- I see a square box with a "no entry" icon on it, and when I click the main applet to enable Java, it shows a "Show all" button in the doorhanger (because there are two different plugins running on the page), and the deployment toolkit plugin listing has an extra "untrusted!" warning on it. – Starfish

Followup: I've submitted this bug to Apple as "Cannot run signed applet in sandbox mode in Java 6", # 15480519. No response of any kind yet (since the 15th), but that's likely normal... – Starfish

I can't find that bug. Can you provide a link to it? – Occident

Hmm. Apparently bugs reported to Apple are all private: #145373 Apparently it's best for more people to submit duplicates instead of clicking "me too" (since they can't) for a bug to get attention. What a waste of time! Here's the text of my bug report, to help you or anyone submit your own: emusictheory.com/appleJava6BugReport.html – Starfish

Answer 1

Reply from Apple to my bug report.

Apple Developer Relations15-Aug-2014 05:12 PM

Engineering has determined that this is an issue for a third party to resolve based on the following:

This issue is with the Oracle manifest checker, which is in conflict with the instructions Oracle has given developers to run applets in Java 7.

We delivered Oracle's Java SE 6 security checker, as they designed in our version of Java SE 6. It is mutually incompatible with future versions of Java, but there is nothing Apple will do to address it, since we are no longer support Java SE 6 on 10.6.8.

We are now closing this bug report.

If you have questions regarding the resolution of this issue, please update your bug report with that information.

Please be sure to regularly check new Apple releases for any updates that might affect this issue.

In other words, they don't support Apple Java any more (even though anyone with OS X 10.6.8 or earlier is forced to use Apple Java), so they're blaming this on Oracle's original spec - which apparently Oracle themselves didn't follow, or this same bug would exist for Oracle Java 6.

Starfish

Answer 2

Okay, I tried A LOT! If not everything! I'm pretty sure there is NO WAY to let a self signed applet run in sandbox mode with the latest update (1.6.0_65-b14-462-10M4609). The only chance I had was to

• downgrade to 1.6.0_51
• remove Permissions tag and param completely from manifest and applet-tag

Boothe

"Signed" applet -- mine aren't self-signed, but this bug breaks them just the same. – Starfish