Thursday May 01, 2014

Deployment Rule Set by Example

Recently I encountered a situation whereby a System Administrator needed to adjust thieir systems to run a specific RIA on an older version of Java. By using Deployment Rule Sets, we were able to achieve the desired outcome. The specific RIA ran using the older version of Java with no prompts to the end users, while all other RIA applications used the latest, most secure version of Java.

This post is intended for System Administrators managing a white list within an organization.

Assessing the environment

In this particular case, the RIA itself was designed to run on Java 6 update 31 (released in February 2012, but public updates for Java SE 6 ended in February 2013). That also means that it does not adhere to the security requirements introduced in a recent Java SE 7 Critical Patch Update. Because this RIA was known to be safe and necessary for business operations, the goal was to be able to execute it with no prompts.

Installing multiple versions of Java

When delegating RIAs to use older Java versions, it is necessary to have at least two installations available:

  1. The latest Java version, which will be used by default except in cases where you configure it to delegate to the older version. We installed this as the default patch-in-place.
  2. The specific older versions needed by the RIA, which will only be accessible through your Deployment Rule Set. We installed this as a static installation to prevent any interference in case that a different Java SE 6 version had to be installed for something else.
    1. Although older versions are not updated with the latest security patches and not recommended for use in production, the Deployment Rule Set mitigates the definition of "in production" because the older JRE is only accessible from explicitly whitelisted areas.

Information about these installation types can be found within a previous post, Managing Multiple Java Versions. Comprehensive documentation is provided by Oracle about silent installation switches for package management as well as disabling third-party sponsors.

Once items were installed, we had two noteworthy locations on the Windows desktops (others may be available as well, but these are the important ones):

  1. C:\Program Files\Java\jre7
  2. C:\Program Files\Java\jre1.6.0_31

Creating the Deployment Rule Set

Instructions on creating a Deployment Rule Set are available in the post Introducing Deployment Rule Sets or in the complete Deployment Rule Set documentation.

The actual deployment rule set used looks like:

<!-- Example Deployment Rule Set that allow a desktop administrator to control end-user's execution of browser applets.
  See http://docs.oracle.com/javase/8/docs/technotes/guides/jweb/security/deployment_rules.html -->
<ruleset version="1.0+">
    <rule>
        <id location="https://java.com/" />
        <action permission="run" version="SECURE" />
    </rule>
    <rule>
        <id location="http://internal.example.com/" />
        <action permission="run" version="1.6.0_31" />
    </rule>
</ruleset>

In this example, we were able to identify and test each item. For example, the first rule checks that users could run the normal Java.com detection applet without any prompts. That demonstrated the correct setup of the DRS. Once successfully set up, the second rule allowed us to target their application.

Ensure the DeploymentRuleSet.jar is signed correctly for each Java installation

Most certificates from Certificate Authorities should work out of the box. The certificate used to sign your Deployment Rule Set must be trusted by each Java installation.

After your Deployment Rule Set is in place (in the documented area), the easiest way to check is to look at the control panel. Instructions for checking this are in the previous post, Introducing Deployment Rule Sets, under the “Verify usage of your rule set on a client desktop.”

Importing certificates into the older Java version

Although most administrators do not need this step, sometimes the older JRE does not contain the newer root certificate. In that case, it is necessary to locate the CA’s root certificate and explicitly import it:

"C:\Program Files\Java\jre1.6.0_31\bin\keytool" -importcert -keystore "C:\Program Files\Java\jre1.6.0_31\lib\security\cacerts" -alias AuthNameNoSpaces -file TheRootTheyProvided.cer

Once we had the root’s certificate inside both keystores, the RIA launched correctly on the older Java 6.

Verifying "is this working right"

Testing your Rule Set involves opening the RIA and verifying execution. Other system tools will help check and verify any assumptions. In addition to launching RIAs like the Java.com detection applet, the regular Task Manager will help understand which versions are getting launched.

Within the basic Task Manager, the Processes tab can show a command line column. In the case that you are launching a different version, you can show the Command Line column. In this screenshot, I’ve shrunk the view but it’s easy to see what I am running.

Screenshot of command-line in Win7 task manager

There are other tools available to view a process chain as well, where you will see a chain that looks like:

  • iexplorer.exe
    • jp2launcher.exe
      • java.exe (from the default JRE installation area)
        • java.exe (from your targeted JRE usage area)

Automating Package Installation

Once the item was identified as working, we were able to integrate the previous silent installation switches to roll the installations out onto different computers.

Most users or members of staff can run basic installers or scripts as needed. Large enterprises with desktop management systems often combine silent installation switches and customization commands (like the keytool import) with MSI creators, and then roll a single file out for installation.

I will refrain from discussing package creation and roll-out in detail. Use the right mechanism that works within your organization.

Reminder about external distribution

The Deployment Rule Set feature is intended for organizations to manage their own configurations. It is not meant as a way to simply "whitelist everything just so warning dialogs go away," "force everyone to never update," or "external users please download this file onto your system to use this application." By default, specifying the version="SECURE" attribute is best unless you know specific reasons restricting compatibility to a specific JRE version.

Publicly distributed Deployment Rule Sets found to contain insecure "whitelist everything" configurations may have their signing certificate blacklisted from future use of Deployment Rule Sets.

Additional Helpful Information

Appendix: Debugging if things to not work as expected

System Administrators new to Java may find the Java console useful to understand what is happening. Most users neither turn on nor see this console.

By turning the console on in the Java control panel, we were able to see execution.

Screenshot of java console

The first line in that file indicates the current version in use: JRE 1.8.0-b132. This is clearly not 1.6.0_31, meaning that it matches the first rule.

When we began using the Deployment Rule Set that delegated to Java 6 update 31, two major things happened:

  1. In the Task Manager process tree, two Java processes appeared. The first was the latest Java, the second was the older version connected to this process.
  2. Because we had the Java console turned on, two consoles appeared: one for each version.

If you press ‘5’ on that console, it will output a significant amount of log information. I won’t paste a sample log here because they can get long, but the really interesting parts look like:

 Sample from log
What it tells us
 Using JRE version 1.8.0-b132 Java HotSpot(TM) 64-Bit Server VM  At the top, this tells us which version is currently in use.
 Lines beginning with “ruleset:”
ruleset: RuleSetParser.parse() returning 2 rules:
 These tell what is happening with the DRS, isolated from other information.
 Lines that talk about “ruleset” and “location”
ruleset: finding Deployment Rule Set for
        title: Java Uninstall Applet
        location: https://java.com/applet/JavaRemovalTool/launch.jnlp
        jar location: https://java.com/applet/JavaRemovalTool/JavaRemovalTool.jar
        jar version: null
        isArtifact: true

 The location information helps me understand if I told the ruleset to whitelist the right place.
Sometimes, though not often, the browser URL and actual application URL are different.
In the example to the left, both are on https://java.com
Although my browser visits an area, /en/download/installed.jsp the actual files are hosted in /applet.
That means copying from my browser’s address bar would not have worked.

Appendix: Identifying applications by Certificate Hash or Location

The two primary ways of creating a deployment rule are by location or certificate hash.

  • Certificate hashes help identify a publisher. For example I could automatically run Oracle RIAs by creating a rule to run RIAs whose certificate hash is 794F53C746E2AA77D84B843BE942CAB4309F258FD946D62A6C4CCEAB8E1DB2C6.
    This rule would take effect regardless of where the RIA was hosted.
  • Location identifies where the RIA (specifically its JAR files) is hosted. This is sometimes easier to copy from a browser’s address bar and can be used in cases where the RIA publisher did not actually sign the RIA.

If the RIA uses LiveConnect (javascript integration), you must create a Location rule to whitelist the hosting domain and accept the LiveConnect calls.

Within the Java Console, there are also ways to locate both of those identifiers.

  • security: SHA-256Certificate finger print: Long certificate hash
  • basic: Plugin2ClassLoader.addURL parent called for http://url.example.com/path/someFile.jar

Those will help identify the items that the RIA plugin is seeing, so then you can look for one of the following messages:

  1. ruleset: Rule hash matches certificate hash (or a similar message about location)
  2. ruleset: no rule applies, returning Default Rule

Monday Nov 25, 2013

Upcoming Exception Site List in 7u51

Over the last year, many new security related features have been implemented. Many of those features have been related to browser plugins for applets and web start applications (RIAs). A number of end users and software vendors have asked for more ways to configure their environment and use of applications. 

The Exception Site List is a way for end-users to control their own application whitelist and continue using RIAs that could not be timely updated to follow previously announced security requirements. The Exception Site List provides a way to continue using a RIA but is not intended as a way to remove all warnings for the user. End-users will still see important prompts, but those prompts will no longer block.

Comparison to Deployment Rule Set

The introduction of the Exception Site List creates a second way for whitelisting RIAs and decreases requirements for system administrators.


 Exception Site List
Deployment Rule Set
 Introduced  Java 7 update 51 (January 2014)
Java 7 update 40 (September 2013)
 Intended for
 End-user System Administrator
 Formatted as
 Plain-text Signed JAR file
 If the two conflict with each-other
 Loses Wins

 For standard policy enforcement, some system administrators may lock down usage of the Exception Site List as they would with any other control panel setting.

Getting Early Access to the Exception Site List

Developers looking to test their applications in advance of 7u51 and use the Exception Site List can download early access of Java 7 update 60 over at the JDK 7 website. That website is the easiest way for developers to get early access of releases.

Adding a site to the Exception Site List

End-users can access the Exception Site List from the Java control panel.

  1. Use your browser to access the RIA that you normally use.
  2. Copy the URL from the address bar.
    Only choose directory paths ending in a / and not a filename.
    • Right: https://www.example.com/someApplication/
    • Wrong: https://www.example.com/someApplication/filename.html
  3. Open the Java control panel.
    • Windows/Mac - Open your system control panel or System Preferences and choose Java.
    • Linux/Solaris - Run the jcontrol command.
  4. Choose the Security tab.
  5. Click the "Manage Site List" button near the bottom.
  6. A new window will open.
    Screenshot of Exception Site List
  7. Click the Add button.
    Screenshot of adding an exception site
    • Right: https://www.example.com/someApplication/
    • Wrong: https://www.example.com/someApplication/filename.html
  8. Click OK. The window will close. You may see an additional prompt if you use an unencrypted protocol such as http or file. Choosing encrypted protocols defends against potential man-in-the-middle attacks.
  9. Back on the control panel, click OK to close it.
  10. Reload the web page on your browser to launch the RIA.

Files behind the Exception Site List

Update Jan 22: The Exception Site List is intended for end-users to create their own whitelist. If you are a System Administrator managing this across many machines, you will find the Deployment Rule Set much easier. Group Policy efforts are better used behind distributing a Deployment Rule Set. You can self-sign a DRS.

The Exception Site List is aimed towards end-users controlling their own Exception Site List.

The file controlling the Exception Site List is stored in the user’s deployment location as described in the deployment configuration. On my Windows 7 laptop, this location is C:\Users\ecostlow\AppData\LocalLow\Sun\Java\Deployment\security\exception.sites

The format is one site per line.

Sample customer support note

As changes are introduced, technical support representatives are usually asked for details. We will be creating a technical support note that can be downloaded and tweaked to help communicate this change to your customers. It is essentially a trimmed down version of this blog post with a stronger How-To message.

Update on Jan 14 2014: Here are the end-user instructions for using the Exception Site List. Otherwise if you need something more customizable, here is a sample Exception Site List support note. This is a docx file but it may appear as a zip.

Monday Sep 09, 2013

New security requirements for RIAs in 7u51 (January 2014)

Java 7 update 51 (January, 2014) intends to include two security changes designed to enhance authentication and authorization for Rich Internet Applications (Applets and Web Start). The default security slider is being updated in a way that will block RIAs that do not adhere to these requirements.  Note: this only applies to RIAs, and not to Java on server or desktop applications run outside of a browser.

Summary:

  • You are required to sign all RIAs (Applets and Web Start applications).
  • You are required to set the "Permissions" attribute within the Manifest.
  • Your application will be affected if it uses Java started through a web browser. Your application will not be affected if it runs anywhere outside of a web browser.

Complete information can be found within the Java 7 update 51 release notes (here once 7u51 is released in January 2014).

Developers:

 As of 7u51, (January 14, 2014), your RIAs must be updated. The updates required are on the packaging and distribution; no API code changes should be required. The impetus for these changes relates to potential re-purposing of sandboxed applications, whereby placing permissions within a signed JAR prevents modification of your specified permission level.
RIAs must contain two things:

  1. Code signatures from a trusted authority. All code for Applets and Web Start applications must be signed, regardless of its Permissions attributes.
  2. Manifest Attributes
    1. Permissions – Introduced in 7u25, and required as of 7u51. Indicates if the RIA should run within the sandbox or require full-permissions.
    2. Codebase – Introduced in 7u25 and optional/encouraged as of 7u51. Points to the known location of the hosted code (e.g. intranet.example.com).

Sample META-INF/MANIFEST.MF file:

Manifest-Version: 1.0
Created-By: 1.7.0_51
Permissions: sandbox
Codebase: www.java.com java.com

This manifest file is created when the JAR is packaged, either through the default jar command, your build tool, or your IDE.

Sample JNLP for launching a web start application:

<?xml version="1.0" encoding="UTF-8"?>
<jnlp href="JavaDetection_applet.jnlp">
    <information>
        <title>Java Detection</title>
        <vendor>Oracle Inc.</vendor>
    </information>
    <resources>
        <jar href="JavaDetection.jar" />
    </resources>
    <applet-desc
          name="Java Detection Applet"
         main-class="JavaDetection"
         width="1"
         height="1">
     </applet-desc>
     <update check="background"/>
</jnlp>

Some developers may notice that the <security /> element is missing from the above JNLP. By providing it within the cryptographically signed JAR file, it is no longer necessary within the JNLP for Java 7 update 51 (January 2014).

See the Development and Deployment Of Rich Internet Applications for full details of JNLPs and the deployment toolkit. For instructions on signing code, see the tutorial Lesson: Signing Code and Granting It Permissions.

Desktop Administrators

If you are a desktop administrator managing Java installations across a series of computers, consider using Deployment Rule Sets to whitelist your internal applications. Deployment Rule Sets allow you to certify that an application is known to be trusted and safe, even if you cannot update the application to adhere to these requirements.

Tuesday Aug 20, 2013

Introducing Deployment Rule Sets

As the Java security model has hardened for browser-based applets, desktop administrators have asked for ways to manage version compatibility and security updates for their end-users.

A new feature is being introduced in Java 7 update 40 called “Deployment Rule Set,” designed to address the issue of security and compatibility in browser applets without affecting normal back-end Java programs like Eclipse, Freemind, or Tomcat. Specifically this deployment rule set addresses two major points:

  1. The desktop administrator’s ability to control Java version compatibility, and default choices on the end-user’s desktop. For example your users may use most recent security updates for most browser applets but still use an old Java 1.6 for that one legacy application that is no longer maintained.
  2. The end-user’s awareness of who created the application and their default interaction (ask, run, or block). By seeing the actual company or signer, the user is protected from running code by someone that they do not know. For example, I would trust “My University” or “Erik Costlow” but not “Unknown publisher” or someone else claiming to be me.

This feature is geared towards two types of users:

Desktop Administrators, who manage a number of users and need to control version compatibility and default dialogs to specific company applets. Desktop Administrators should learn how to control Java across these user systems. For example, “automatically run browser applets signed by our company” or “run all our browser applets with the latest secure version, except for this one internal system that we know needs Java 1.6.”

Developers, who create Java applets and Web Start applications should be aware of the role that deployment rule sets play on their end-user’s desktop.

How to create a deployment rule set

By creating a deployment rule set, desktop administrators can control execution and dialog prompts for desktop users and allow them to run known Java applets, either created by the company or used in critical systems.

Creating a deployment rule set involves a set of steps done once that can then scale out to any number of users and continue working in their future Java updates:

  1. Identify critical applets and web start applications, either by location (e.g. http://payroll.example.com), name (e.g. Solitaire), or code-sign hash.
  2. Create a file called ruleset.xml
  3. Package your ruleset.xml into a signed DeploymentRuleSet.jar
  4. Deploy your DeploymentRuleSet.jar to user desktops
  5. Verify usage of your rule set on a client desktop

Identify critical Applets and Web Start applications

Find locations of known applets that your users interact with as part of their normal work. There are many means for gathering this information, from asking/monitoring users to speaking with your director of engineering if their team is creating applets. Ultimately, they can be listed through three means:

  1. Location
    • This is a pattern matcher for URLs. You can identify applets through a simple combination of wildcards and automatic directories.
    • The benefit of location is that it is easy to collect the right information.
    • Examples:
      • https://payroll.example.com
      • *.example.com/panel
        This will implicitly cover anything located beneath the panel folder
  2. Certificate Hash
    • If you are following the security practice of signing your code so that users know your applets, you can provide a SHA-256 hash of your public certificate.
    • The benefit of a certificate hash is that it recognizes a publisher, irrespective of location. The downside is that you must find the appropriate certificate.
    • Examples of SHA-256 hashes look like 63 characters of hexadecimal: 794F53C746E2AA77D84B843BE942CAB4309F258FD946D62A6C4CCEAB8E1DB2C6
    • To get these hashes, download a signed jar file or obtain one from the developers and run:
      1. keytool -printcert -jarfile MyProgram.jar > cert.txt
      2. Open cert.txt and find the earliest relevant signature. For example, I chose ours:
        Owner: CN="Oracle America, Inc.", OU=Software Engineering, OU=Digital ID Class 3 - Java Object Signing, O="Oracle America, Inc.", L=Redwood Shores, ST=California, C=US
        and then copied the hash line appearing a little later:
        SHA256: 79:4F:53:C7:46:E2:AA:77:D8:4B:84:3B:E9:42:CA:B4:30:9F:25:8F:D9:46:D6:2A:6C:4C:CE:AB:8E:1D:B2:C6
      3. Remove the : separator characters.
  3. Title
    • Look at the JNLP launcher to identify the title of the application.
    • Title must occur only with another attribute, like location or certificate. Title may not be used alone since it exists outside signed jars and deployed locations.

For the time being, just create a list of these.

Create a file called ruleset.xml

Once you have a list of critical applets, the next step is to create a single file called rulset.xml that will look like this:

<!-- Example Deployment Rule Set that allow a desktop administrator to control end-user's execution of browser applets.
  See http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/deployment_rules.html -->
<ruleset version="1.0+">
	<rule>
		<id location="http://payroll.example.org" />
		<action permission="run" />
	</rule>
	<rule>
		<id location="http://knownvendor.example.com/program" />
		<action permission="run" version="SECURE-1.6" /><!-- For example if an application is known not to work on Java 1.7 -->
	</rule>
	<rule>
		<id location="http://localhost" />
		<action permission="run" />
	</rule>
	<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>
	<rule>
		<id location="http://*.example.com">
			<certificate algorithm="SHA-256"
				hash="..." />
		</id>
		<action permission="default" version="SECURE" />
	</rule>
	<rule>
		<id /><!-- Because this is both blank and shown last, it will be the default policy. -->
		<action permission="block">
			<message>Blocked by corporate. Contact myemail@mycompany.com if you need to run this app.</message>
			<message locale="fr">Bloqué par l'entreprise. Contacter myemail@mycompany.com si vous avez besoin d'exécuter cette application.</message>
		</action>
	</rule>
</ruleset>

Complete details for creating this file can be found in the Deployment Rule Set documentation, but the gist is to specify the default action of which should run (with no interaction from the user), which should perform the default behavior (prompting the user), and which should be automatically blocked (explaining why).

Package your ruleset.xml into DeploymentRuleSet.jar

Packaging your ruleset allows the desktop administrator to apply cryptographic signatures and prevent users from overriding your policy. This requires usage of a trusted signing certificate. The easiest route to get a signature is to buy one from a certificate authority like Symantec/Verisign, Comodo, GoDaddy, or any other; but in this case I have instructed my JVM to use a custom costlow-ca certificate authority (which only works on my machine). The default certificate authority list contains about 80 authorities from which you may purchase a signing certificate.

C:\Users\ecostlow\DeploymentRuleSet>jar -cvf DeploymentRuleSet.jar ruleset.xml
added manifest
adding: ruleset.xml(in = 1492) (out= 612)(deflated 58%)

C:\Users\ecostlow\DeploymentRuleSet>jarsigner -verbose -keystore "c:\Users\ecostlow \javakeystore_keepsecret.jks" -signedjar DeploymentRuleSet.jar DeploymentRuleSet.jar costlow-ca
Enter Passphrase for keystore:
 updating: META-INF/MANIFEST.MF
   adding: META-INF/COSTLOW-CA.SF
   adding: META-INF/COSTLOW-CA.RSA
  signing: ruleset.xml

Deploy your DeploymentRuleSet.jar to user desktops

After creating the signed jar, desktop administrators should copy the DeploymentRuleSet.jar to the documented area for their platform so that rules are enforced for all users, across Java updates.

Verify usage of your rule set on a client desktop

For end-users, simply have them visit a website like http://java.com/en/download/installed.jsp and verify their Java version (this site uses an applet, so see if it runs).

For desktop administrators, test your Deployment Rule Set by opening the Java Control Panel and navigating to the Security tab:


Clicking the “View the active Deployment Rule Set” should show you your same ruleset.xml file.

End Result

After performing the steps above, desktop administrators can now better control usage of the Java dialogs and prompts for managed users that will function across Java updates. To make changes in the future, simply roll out a new distribution of the DeploymentRuleSet.jar.

Notes and what Deployment Rule Set is not:

The Deployment Rule Set features is intended for mostly enterprise users to manage their own configurations. It is not meant as a way to simply "whitelist everything just so warning dialogs go away," "force everyone to never update," or "external users please download this file onto your system to use this application." By default, specifying the version="SECURE" attribute is best unless you know specific reasons indicating compatibility with a specific JRE version.

Publicly distributed Deployment Rule Sets found to contain insecure "whitelist everything" configurations may have their signing certificate blacklisted from future use of Deployment Rule Sets.

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 2015
SunMonTueWedThuFriSat
   
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
22
23
24
25
26
27
28
29
30
  
       
Today