Friday Oct 18, 2013

7u45 Caller-Allowable-Codebase and Trusted-Library

Java 7 update 45 (October 2013) changed the interactions between JavaScript and Java Applets made through LiveConnect. The 7u45 update is a critical patch update that has also raised the security baseline and users are strongly recommended to upgrade.

Versions below the security baseline used to apply the Trusted-Library Manifest attribute to call between sandboxed code and higher-privileged code. The Trusted-Library value was a Boolean true or false. Security changes for the current security baseline (7u45) introduced a different Caller-Allowable-Codebase that indicates precisely where these LiveConnect calls can originate. For example, LiveConnect calls should not necessarily originate from 3rd party components of a web page or other DOM-based browser manipulations (pdf).

Additional information about these can be located at “JAR File Manifest Attributes for Security.”

The workaround for end-user dialogs is described on the 7u45 release notes, which explains removing the Trusted-Library attribute for LiveConnect calls in favor of Caller-Allowable-Codebase. This provides necessary protections (without warnings) for all users at or above the security baseline. Client installations automatically detect updates to the secure baseline and prompt users to upgrade.

Warning dialogs above or below

Both of these attributes should work together to support the various versions of client installations. We are aware of the issue that modifying the Manifest to use the newer Caller-Allowable-Codebase causes warnings for users below the security baseline and that not doing it displays a warning for users above.

Manifest Attribute 7u45 7u40 and below
Only Caller-Allowable-Codebase No dialog Displays prompt
Only Trusted-Library Displays prompt No dialog
Both Displays prompt (*) No dialog
This will be fixed in a future release so that both attributes can co-exist.

The current work-around would be to favor using Caller-Allowable-Codebase over the old Trusted-Library call.

For users who need to stay below the security baseline

System Administrators that schedule software deployments across managed computers may consider applying a Deployment Rule Set as described in Option 1 of “What to do if your applet is blocked or warns of mixed code.”

System Administrators may also sign up for email notifications of Critical Patch Updates.

Tuesday Oct 15, 2013

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. 

LiveConnect changes in 7u45

Java 7 update 45 (October 2013) introduces a new warning to users of LiveConnect applications. LiveConnect is a technology for Rich Internet Applications that allows JavaScript on a web page to make calls into an RIA, allowing the two to work together and load content. RIAs that do not use LiveConnect are unaffected by this change.

What changed: Users are prompted to confirm a domain when it makes its first LiveConnect call.
How is this different: Previously, LiveConnect calls were allowed by default.

For the first LiveConnect call (per-site), the Java plugin will ask the user if they want to allow interactions from [this domain] to interact with the currently running RIA. This allows the user to confirm known sources (such as the hosting site) and block alternate sources, such as on-page advertising networks or browser plugins. Prompts will displayed when that a web page performs a LiveConnect call. Prompts about LiveConnect cannot be made beforehand because the caller does not exist.

The LiveConnect warning looks like this:
LiveConnect Dialog: Allow access to the following application from this web site?

Developers looking to avoid this warning within their applications may use the optional Caller-Allowable-Codebase attribute within their JAR file’s Manifest.  The Caller-Allowable-Codebase attribute provides a list of domains that can make LiveConnect calls in to the application. This is different than the optional Codebase attribute, which describes the domains from which JAR files may be loaded, although both use similar syntax.

META-INF/MANIFEST.MF

Manifest-Version: 1.0
Created-By: 1.7.0_45
…
Caller-Allowable-Codebase: example.com *.example.net

RIA developers looking to understand which messages will appear as a result of the end-user’s security slider may consult the Rich Internet Deployment Process flowchart. This chart depicts the checks that will be performed on a user’s system, from version-update checks through checking the signature and appropriate Manifest Permissions. The checks are split into two categories: Before your RIA and With your RIA.

Before your RIA:

  1. Is Java registered in the browser?
  2. Does a rule exist on the user’s system to whitelist this RIA? (e.g. a Deployment Rule Set)
  3. Is the user’s Java version at or above the security baseline?

With your RIA:

  1. Does the RIA have a valid code signature?
  2. Does the RIA meet requirements of the user’s security slider?
  3. Are LiveConnect calls from [this domain] allowed?
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
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today