Thursday Apr 17, 2014

Secure Coding Guidelines for Java SE

With so much happening around the Java platform, it’s understandable if you missed the recent improvements we made to the Secure Coding Guidelines for Java SE.  In January 2014 the Java Platform Group released a significant update, Java 7 Update 51 establishing code-signing as the default for Applets and Web Start applications.  Following in March 2014, we hit another major milestone with the long anticipated release of Java SE 8.

There are a number of improvements to the Secure Coding Guidelines for Java SE.  On the surface, the larger domains of the coding guidelines like Fundamentals and Denial of Service are the same but content has been improved throughout each domain based upon changes to Java’s threat landscape.  Likewise, small but noteworthy improvements to content navigation were made to the domains in table of contents facilitating quick navigation for readers.

Beyond content improvements, code examples were refreshed to highlight new Java 8 features like Lambda.  While our coding guidelines are updated for Java SE 8, most guidance is relevant to older versions like Java SE 7.  Please keep in mind secure application coding and design is only one component in a secure solution.  Building secure solutions requires OS security hardening, application and infrastructure hardening, patching all components on a timely schedule, etc.  More information about Java security is available in the Security Resource Center for Java.

Monday Apr 07, 2014

JavaOne 2014 Security Track Early Acceptance Sessions

J1 LogoJavaOne 2014 is Oracle's flagship software developers conference event for Java.  Security has been a focus at the conference for many years but last year Oracle brought security to the forefront by including it as a track.  If you have ideals for interesting Java security sessions we would be delighted to review them.  The JavaOne CFP is open until April 14, 2014.

 Back to the security track, each year the tracks highlight their early acceptance sessions to build momentum for the conference.  This year I would like to highlight the following early acceptance sessions for the security track and show a little of what we are planning.  

CON2120 Anatomy of Another Java Zero-Day Exploit

Presenter:  David Svoboda, Software Security Engineer, Carnegie Mellon

Abstract:  Java was recently hit by several major exploits. These exploits were written in pure Java and relied on several obscure components of the Java library. Understanding how exploits undermine Java security is a fundamental step in understanding and improving Java security and producing secure Java code. Consequently, this session demonstrates and examines a public exploit. It dissects the code of the exploit and illustrates how the exploit managed to attack an unpatched Java Virtual Machine, focusing on the techniques the exploit used, with references to relevant guidelines from the CERT Oracle Secure Coding Standard for Java. The session concludes with an explanation of how Java was patched to defeat the exploit.

CON1713 Leveraging Open Source for Secure Java Website Construction

Presenter:  Jim Manico, Secure Coding Instructor, Manicode Security (JavaOne Rock Star)

Abstract:  The need to master the skills required to build secure Java web and webservice applications gets stronger every day. There is help for you in the world of opens source! Do not build your own web application security controls from scratch! This presentation describes the use of several Oracle, OWASP, Apache and Google open source Java projects that are essential tools for constructing a secure web application.

In addition to community speakers, we will have Oracle experts from the Java security team to discuss new security features and improvements like the recent release of Java SE 8.  See you at JavaOne!

Tuesday Apr 01, 2014

Java 8's new Type Annotations

Java 8 introduces two important changes to Annotations designed to help developers produce better code and improve the accuracy of automated code analysis to verify that quality.

Quick Annotations Webinar

There is a great video explaining the new improvements in the Java 8 Launch Webinars called “Enhanced Metadata - Annotations and Access to Parameter Names” by Alex Buckley and Michael Ernst.

Annotation Improvements

Type Annotations allow developers to write annotations in more places than before. The compiler can then verify these annotations, for example identifying uses of null values, accidental value modifications, and cases where data crosses a trust boundary without proper validation. By moving some annotatable information from the Javadoc (understood only by people) and into the code (understood by both people and analyzers), it is easier to understand intent and verify the absence of certain errors.

Repeating Annotations make it easier for authors of these annotations because there is less need for wrapper annotations.

The Checker Framework provides a few Type Annotations that could benefit both library and application developers, such as:

  • @NonNull – The compiler can determine cases where a code path might receive a null value, without ever having to debug a NullPointerException.
  • @ReadOnly – The compiler will flag any attempt to change the object.  This is similar to Collections.unmodifiableList, but more general and verified at compile time.
  • @Regex – Provides compile-time verification that a String intended to be used as a regular expression is a properly formatted regular expression.
  • @Tainted and @Untainted – Identity types of data that should not be used together, such as remote user input being used in system commands, or sensitive information in log streams.
  • @m – Units of measure ensures that numbers used for measuring objects are used and compared correctly, or have undergone the proper unit conversion.

Putting Type Annotations on your code

Java SE 8 allows type annotations anywhere that a type is used. Previously, annotations were only allowed on definitions. Some examples of this are:

Annotation Example Meaning
@NonNull List<String>
A non-null list of Strings.
List<@NonNull String>
A list of non-null Strings.
@Regex String validation = "(Java|JDK) [7,8]"
Check at compile time that this String is a valid regular expression.
private String getInput(String parameterName){
final String retval = @Tainted request.getParameter(parameterName);
  return retval;
}
The object assigned to retval is tainted and not for use in sensitive operations.
private void runCommand(@Untainted String… commands){
ProcessBuilder processBuilder = new ProcessBuilder(command);
  Process process = processBuilder.start();
}
Each command must be untainted. For example, the previously tainted String must be validated before being passed in here.

For reading annotations, the way to look at them is that they annotate the next item after that isn’t also an annotation.

Automating issue detection

When working on software, it helps to uncover potential problems early. A problem caught early is easier to fix than one caught later, and a potential problem caught right away is easier still. Some annotations allow problems to be caught immediately. The @Override annotation allows the compiler (or a static analysis tool) to immediately determine if a developer wrote the wrong method signature.

Other annotations, like @NonNull and @Readonly can be used by analyzers like the Checker Framework, FindBugs, Eclipse, NetBeans, IntelliJ, or a commercial analyzer. Those analyzers can then be run at compile time, through IDE background compilation, Ant/Maven, or continuous integration.

Type Annotations tell those analyzers what to look for. Without the Type Annotations in place, these analyzers would still be able to locate null-usage and write-modifications but would not know that they are wrong. The result would then be false negatives (no issue reported) or false positives (incorrect issues reported).

Teamwork

Type Annotations can greatly benefit teams that are geographically distributed or contain many members. By placing Type Annotations inside the code and running automated checks before commits or during integration builds, team members can identify situations where one change inadvertently affects another.

Optional Type Annotations are not a substitute for runtime validation

Before Type Annotations, the primary location for describing things like nullability or ranges was in the javadoc. With Type annotations, this communication comes into the bytecode in a way for compile-time verification.

Your code should still perform runtime validation.

Annotation validation versus Business Validation

Type Annotations are best used with common forms of validation that relate to computer science. There are certain types of business validation that are not applicable.

Well-suited for Type Annotations
Likely not well-suited for Type Annotations
  • Null value checks.
  • Numeric range checks.
  • Basic type checks, such as regular expressions.
  • Assignments and updates (e.g. read-only)
  • Dataflow validation detection (e.g. have the incoming function arguments gone through the right validation functions)
  • This function cannot be executed outside certain hours or on government holidays.
  • Access to a feature requires a certain account-type.

Appendix

Annotations in core Java

There is no set of default type annotations available out of the box in the Java SE 8 platform. All previous examples in this post used the Checker Framework. The Type Annotations in Java SE 8 focused on the ability to put annotations in the right areas to describe a program. A separate, currently inactive JSR-305 (not part of Java 8) exists for identifying what those annotations should be.

The Checker Framework currently uses Java Annotation Index Files to gain comparable support for the core Java runtime and targeted libraries, or previous Java versions like Java SE 7 or 6.

Removal of APT

JDK 8 also removes a legacy annotation processing tool, named apt. Few users should be affected by this change. This was done as part of JEP 117 because everything required for annotation processing appears in either javax.annotation.processing or javax.lang.model.

Tuesday Jan 28, 2014

JDK 8 will use TLS 1.2 as default

Transport Level Security (TLS) is designed to encrypt conversations between two parties and ensure that others can neither read nor modify the conversation. When combined with Certificate Authorities, a proper level of trust is established: we know who is on the other end of the conversation and that conversation is protected from eavesdropping/modification.

Support for TLS 1.2 first appeared in JDK 7 (2011). For compatibility reasons, it is enabled by default on server sockets but disabled on clients. Since that time, the industry has made considerable improvements to address interoperability and backwards compatibility.

We are setting JDK 8 to use TLS 1.2 as the default for two reasons:

  1. TLS is backwards-compatible. After upgrading the default to 1.2, systems using 1.1 and 1.0 will continue to function*.
    1. * Unless configured to use an algorithm that was removed for security reasons. Few systems are affected by this.
    2. For a complete description of TLS 1.2, please see RFC 5246.
    3. A quick summary of TLS/SSL differences is available from yaSSL.
  2. It strengthens the protection of internet communications against eavesdropping.

For those testing JDK 8 early access, this first occurred in build 122.

TLS is transparent to most users and developers. For those that would like more details, we will cover:

  • Threats and the role of encryption
  • Compatibility with the JDK and other systems
  • Understanding your TLS implementation
  • Other considerations for TLS

Threats and the role of encryption

With a new well-motivated IETF working group for encryption as well as wide industry support for TLS 1.2, the time is right to update system defaults.

Qualys SSL Labs has done great research in depicting a threat model for TLS. Their best practices in dealing with the TLS threat model (specifically "2.2 use secure protocols") support this move.

Compatibility with the JDK and other systems

TLS 1.2 is designed to be backwards-compatible as described in the RFC Appendix E (above). If a 1.2 client connects to a server running a lower version, the client will adjust. If a lower client connects to a server running 1.2, the server will adjust. Because of backwards-compatibility, clients supporting TLS 1.2 will receive improved communications and older clients will continue to function.
  • We added support for TLS 1.2 in JDK 7 (July 2011) although it was not the default. JDK 8 (March 2014) will use TLS 1.2 as the default.
  • OpenSSL added support for TLS 1.2 in version 1.0.1 (March 2012). Most Linux distributions and scripting languages use OpenSSL.
  • Microsoft supported TLS 1.2 in Windows 7. Internet Explorer and .NET follow accordingly. TLS 1.2 was first enabled by default in Internet Explorer 11 (October 2013).
  • Firefox turned TLS 1.2 on by default in version 27 (February 2014).
  • Chrome supported TLS 1.2 in version 29 (August 2013).
  • Etc.

Adoption statistics from the Trustworthy Internet's SSL Pulse show a sufficient number of internet-facing systems using TLS 1.2 and compatible ciphers.

Understanding your TLS implementation

Developers or System Administrators can test servers and clients through the Qualys SSL Labs (server or client) or a different How’s My SSL website.

System Administrators can view their system’s TLS implementation to monitor clients or disable specific TLS versions. For example some system administrators in highly sensitive businesses may want to disable older TLS versions from ever being used.

View your client’s version through a GUI

  1. Open the Java Control Panel
  2. Navigate to the Advanced tab.
  3. At the bottom, there is an “Advanced Security Settings.”
  4. Check or uncheck the "Use TLS X.Y" box.

On a server or without a GUI

  1. To set this for everything:
    1. Open the deployment.properties file, either user-level or system-level.
    2. Set the appropriate property
      deployment.security.TLSvX.Y=false
  2. To set for a specific application or script:
    1. Use the startup flag -Ddeployment.security.TLSvX.Y=false

Other Considerations for TLS

The InfoQ article, Keeping Your Secrets, covers additional information for developers looking to understand more about transport security and encryption. Outside the role of TLS protocol version, that article covers good techniques to safeguard information:

For System Administrators (or some Developers): Perfect Forward Secrecy can be used in Java TLS connections. Using Perfect Forward Secrecy protects past conversations: in the event that if keys are lost in the future, someone cannot decrypt past conversations. As is common with TLS implementations, Perfect Forward Secrecy is not enabled by default. Those that do want to use it can update their https.cipherSuites property. Common values for this property are:

  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_DHE_RSA_WITH_AES_128_CBC_SHA
  • Anything on the Algorithm Standard Name list that start with TLS (Transport Level Security) followed by a type of DHE (Diffie-Hellman Exchange).

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.

Friday Nov 15, 2013

Security Resource Center

We recently launched a new Java security resource center on the Oracle Technology Network.The goal of this page is to aggregate security-related information for members of the Java community based on their roles.

The resource center is not meant for specific technical features. Features are different and well covered in documentation sections like cryptography. The resource center focuses more towards "security is everyone's responsibility" in discussing how features and people work together.

One of the first items added to the security resource center is an RIA Checklist that developers and managers can use to accommodate previously announced changes in Java 7 update 51 (January 2014).

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?

Thursday Oct 10, 2013

Signing code for the long-haul

With recent code-signature requirements for Rich Internet Applications, I have received a few good questions from different types of developers

  • What is the role of code signing?
  • How do I prevent my signature from expiring? 

What is the role of code signing?

Code signatures allow people who will receive and use your code to determine that you are, in fact, the publisher and that no one else has intentionally or accidentally modified your deliverable. Code signatures protect against these modifications within your supply chain, when moving across a network, or when appearing through 3rd party distribution channels. Code signatures offer a level of repudiation: even though an imposter tries to look like your app, both you and your customers can prove that it isn’t.

There are two concepts for this level of trust:

  1. Identity, the application providing a claim as to who wrote it.
  2. Authentication, the JRE automatically validating this claim against a set of known trust stores.

The way that this information is provided and checked is through industry standard Certificates, which tie together information about the signers (their identity) with the ability to mathematically verify it (through a key).

For a description on why code signatures are taking a more prominent role within the Java Platform, please see our previous entry, Code Signing – Understanding Who and When.

How do I prevent my signature from expiring?

Trusted Timestamping, introduced in Java 5 (2004), allows your customers to validate your signature even after the certificate has expired. When you sign a JAR file, the Timestamp Authority uses their clock to act as a notary and cryptographically write the date and time into your file.

Without this timestamp, users would only be able to validate your signature based on their current date and time. This could be problematic for long-running or embedded systems because the standard X.509 Certificates contain a NotAfter date that typically ranges from one to four years.

You interact with timestamp authorities when signing code with jarsigner’s TSA argument:

jarsigner -tsa http://timestamp.verisign.com …

When your signed file provides a timestamp, Java is able to use that information within the PKIXParameters and determine:

  1. Do I trust this timestamp authority to act as a notary?
  2. Is the signature date before the certificate’s time of expiration?
  3. Based on Certificate Revocation Lists, was this certificate valid on or before the signature date?

If the answer to all questions is yes, then the signature is deemed valid even if the certificate has expired. Therefore, signed code on embedded devices will continue to operate beyond the Certificate’s lifetime.

Several trusted timestamp authorities are listed in the previous post, “Code signing: Understanding who and when.”

A note about Certificate Authorities and revocation lists

Part of the acceptance criteria for being included in Java’s root certificate authority program is allowing back-dating of certificate revocation in the event that a private key is lost or stolen and continuing to publish revocation information even after a Certificate’s public expiration.

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 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