What to do if your applet is blocked or warns of “mixed code”?

Recent security changes, including the October 7u45 critical patch update, for RIAs (Applets & Web Start applications) have affected several audiences in different ways. Other types of applications (such as back-end server applications, web applications, middleware, client-installed applications, and others) are unaffected by these changes.

Two notable changes are:

  1. Java 7 update 45 (October 2013) introduced changes to the LiveConnect model of JavaScript calling Java RIAs whereby additional warnings are raised in certain situations.
  2. In the future, Java 7 update 51 (January 2014) will introduce a code-signing requirement for RIAs.

Affected RIAs should be patched and updated immediately by their developers. Sometimes this is not feasible, such as cases of an application purchased from a vendor, an RIA is burned into device firmware, or the RIA has been in use for years and nobody knows the maintainer.  In those situations, System Administrators can take steps to adapt to these changes if they prefer not to be notified.

Option 1

System Administrators can follow the instructions for creating a Deployment Rule Set and create appropriate rules to whitelist the RIA and javascript domains:

  1. First, identify the location of JavaScript where your web pages will be calling in to Java. For example, by whitelisting your own domains and thereby disallowing alternate sources.
    <rule>
        <id location="https://www.example.com/program" />
        <action permission="run" version="SECURE" />
    </rule>
    This is an important step because web pages are often made of many components, such as analytics, image hosts, and other pieces. Whitelisting your domain prohibits others from calling in to your Java application.
  2. If the RIA is hosted at a different location, such as a content delivery network, you can whitelist it separately with the hash of its certificate.
    <rule>
        <id>
            <certificate algorithm="SHA-256"
                hash="794F53C746E2AA77D84B843BE942CAB4309F258FD946D62A6C4CCEAB8E1DB2C6" /><!-- Oracle's public certificate hash. Having this will allow things like the Java.com secure version check applet. -->
        </id>
        <action permission="run" />
    </rule>

Option 2

System Administrators or Developers can overwrite the application’s signature and add the appropriate Manifest entries. While it does not involve code changes, modifying a JAR file will break the digital signature and requires generating a new one. If you take someone else’s signed document and make changes – your changes invalidate the document they signed, so you need to white-out their signature and apply your own.

There is an existing tutorial for updating JAR files and Modifying a Manifest file. The subset of steps needed for updating to the latest requirements are:

  1. Identify the appropriate JAR file by looking at the JNLP deployment descriptor file. There is a JAR resource specification inside that looks like:
    <jar href="JavaDetection.jar" />
  2. Extract the MANIFEST.MF file:
    jar -xf JavaDetection.jar META-INF/MANIFEST.MF
  3. Open META-INF/MANIFEST.MF in a text editor. Modify the entries that you need, following the Security Manifest Properties documentation:
    1. Permissions – either sandbox or all-permissions. Sandbox is recommended unless the RIA needs further permissions.
      e.g. Permissions: sandbox
    2. Codebase – the original developer often does not have enough information to supply this optional attribute because they do not know where it will be deployed. Provide your hosting location and domain.
      e.g. Codebase: https://www.example.com
    3. Caller-Allowable-Codebase – If your RIA requires a calling web page to make LiveConnect calls into the RIA, providing this optional attribute will allow those calls without additional user prompts. The original developer may not have this information because they might not know where it will be deployed. For LiveConnect, this must be provided even if it is the same as the Codebase.
      e.g. Caller-Allowable-Codebase: https://www.example.com https://customers.example.net
  4. Place your MANIFEST.MF file back into the JAR file:
    jar -ufm JavaDetection.jar META-INF\MANIFEST.MF
  5. The final step is to sign the JAR file using your own certificate.
    1. Optional: If you want to verify that these modifications invalidated the previous signature :
      jarsigner -verify JavaDetection.jar
    2. Apply your own signature to the file:
      jarsigner -verbose -keystore "c:\Users\ecostlow \javakeystore_keepsecret.jks" -signedjar JavaDetection.jar -tsa http://timestamp.verisign.com your-certificiate-alias
After updating the MANIFEST.MF file, you can publish the new JAR files for users to access. 
Comments:

So apparently the Caller-Allowable-Codebase manifest entry does not work if the Trusted-Library manifest entry is present. If I remove the Trusted-Library entry, my applet does not work. So, now what? Why does Caller-Allowable-Codebase fail to suppress the warning if Trusted-Library is present in the manifest?

Posted by guest on October 16, 2013 at 11:47 AM PDT #

Same situation here. Trusted-Library was required for an earlier security update to suppress Mixed Code warnings. Now we need to remove it and set Caller-Allowable-Codebase instead to suppress the LiveConnect warnings. So now mixed code warnings are reappearing for people using earlier than update 45 JREs.

The only solution seems to be to dynamically deploy different applets based on the JRE installed. Am I missing something ?

Posted by Mathieu Fortin on October 17, 2013 at 04:27 PM PDT #

Pity Caller-Allowable-Codebase doesn't work when combined with Trusted-Library and pack compression. That seems like a critical bug that should've blocked 7u45 release; now we have to roll back that manifest entry, do a release, and then do a second release when the bug is fixed before 7u50 makes it a requirement.

http://www.oracle.com/technetwork/java/javase/7u45-relnotes-2016950.html
Synopsis: Caller-Allowable-Codebase may be ignored when used with Trusted-Library.

And as Mathieu pointed out, the updated release will cause security warnings for people who haven't upgraded Java.

Posted by Andrew Herron on October 21, 2013 at 08:45 PM PDT #

I'm dealing with digital certificate using Applet. It was working fine before Java update 1.7.0_45. I followed same you instructed but its throwing exception.

java.security.AccessControlException: access denied ("java.security.SecurityPermission" "authProvider.SunMSCAPI")
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at sun.plugin2.applet.AWTAppletSecurityManager.checkPermission(Unknown Source)
at sun.security.mscapi.KeyStore.engineLoad(KeyStore.java:755)
at sun.security.mscapi.KeyStore$MY.engineLoad(KeyStore.java:62)
at java.security.KeyStore.load(Unknown Source)
at EncryptionApplet.initializeBrowserKeyStore(EncryptionApplet.java:146)
at EncryptionApplet.DisplayCertificatesInBrowser(EncryptionApplet.java:730)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at sun.plugin.javascript.Trampoline.invoke(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at sun.plugin.javascript.JSClassLoader.invoke(Unknown Source)
at sun.plugin2.liveconnect.JavaClass$MethodInfo.invoke(Unknown Source)
at sun.plugin2.liveconnect.JavaClass$MemberBundle.invoke(Unknown Source)
at sun.plugin2.liveconnect.JavaClass.invoke0(Unknown Source)
at sun.plugin2.liveconnect.JavaClass.invoke(Unknown Source)
at sun.plugin2.main.client.LiveConnectSupport$PerAppletInfo$DefaultInvocationDelegate.invoke(Unknown Source)
at sun.plugin2.main.client.LiveConnectSupport$PerAppletInfo$3.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.plugin2.main.client.LiveConnectSupport$PerAppletInfo.doObjectOp(Unknown Source)
at sun.plugin2.main.client.LiveConnectSupport$PerAppletInfo$LiveConnectWorker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

Posted by Vicky Thakor on October 22, 2013 at 12:06 AM PDT #

Post a Comment:
Comments are closed for this entry.
About

Science Duke
This blog contains topics related to Java SE, Java Security and Usability. The target audience is developers, sysadmins and architects that build, deploy and manage Java applications. Contributions come from the Java SE Product Management team.

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
2
3
4
5
6
8
9
10
11
12
13
14
15
16
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today