Update Release Notes

• Update Release Notes Index

Java™ SE Development Kit 7, Update 25 (JDK 7u25)

The full version string for this update release is 1.7.0_25-b15 (where "b" means "build") except for Windows on which it is 1.7.0_25-b17. The version number is 7u25.

Highlights

This update release contains several enhancements and changes including the following:

• On line Certificate Revocation Checking
• New JAR Manifest File Attributes
• Best Practices for Applet & Web Start Deployment
• LiveConnect Blocked under Some Conditions
• New property for Secure Validation of XML
• Java API Documentation Updater Tool
• Help for Security Dialogs
• Change in Networking API Implementation on Windows platforms
• Changes to Runtime.exec

Olson Data 2013b

JDK 7u25 contains Olson time zone data version 2013b. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baselines

The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 7u25 are specified in the following table:

For more information about security baselines, see Deploying Java Applets With Family JRE Versions in Java Plug-in for Internet Explorer.

JRE Expiration Date

The expiration date for JRE 7u25 is November 15, 2013.

Blacklist Entries

The JDK 7 blacklist is now dynamically updated to include the following:

• F5 Client products
• Java extension installer for JavaFX

Order of Signing the Jar Files

In JDK 7u25, a bug that incorrectly treated jars in non-jnlp applets with an unsigned index.list entry as properly signed if the rest of the jar was signed, has been fixed. As a result of this fix, signed jars that contained an unsigned index.list will now either trigger the unsigned code warning dialog or be blocked depending on the security level and whether the JRE is above or below the security baseline.

To properly sign a jar, index entries must be created before the jar is signed. For more information see 8016771.

Local Applets return NULL for codebase

Beginning with JDK 7u25, an applet's getCodeBase() method will return NULL when the applet is running from the local file system.

Certificate Revocation

Before signed Java applets and Java Web Start applications are run, the signing certificate is checked to ensure that it has not been revoked. Advanced options in the Java Control Panel(JCP) can be set to manage the checking process. For more information on these options.

Under normal circumstances revocation checking will have a slight impact on startup performance for applets and web start applications. Enterprises with managed networks and without access to the Internet (resulting in no access to the revocation services provided by Certificate Authorities) will see a significant delay in startup times.

To avoid such delay, they may choose to disable on line revocation checking through the JCP. Note that disabling on line revocation checking should only be considered in managed environments as it decreases security protections.

New JAR Manifest File Attributes

JDK 7u25 release introduces the permissions and codebase attributes in the JAR Manifest File. These attributes are used to verify that the application is requesting the correct permissions level and is accessed from the correct location. See Preventing the Repurposing of an Application document.

Developers are advised to utilize at least the new permissions attribute, and if possible the codebase attribute as well. In future releases, applications that do not include these protections may be blocked or subjected to additional warning dialogs.

Best Practices for Applet & Web Start Deployment

As a result of various security changes and improvements, the following best practices are recommended for Applet and Web Start deployment:

• Sign all JAR files using a Public Key Code Signing Certificate.
• In the application jar manifest file include the permissions keyword with the desired permissions level, and if possible the codebase attribute as well.

For more information see Deployment Best Practices.

LiveConnect Blocked under Some Conditions

LiveConnect calls from JavaScript to Java API are blocked when the Java Control Panel security slider is set to Very High level, or when the slider is at the default High level and the JRE has either expired or is below the security baseline.

New property for Secure Validation of XML

To avoid potential security issues with XML signatures, a secure validation mode has been added whereby signatures that contain potentially hostile constructs are rejected and not processed.

For this purpose, the following new private property is added to the JDK:

The property can be set by an application by calling the setProperty method of the javax.xml.crypto.dsig.dom.DOMValidateContext class with the name of the property above and a Boolean value.

When set to true, this property instructs the implementation to process XML signatures more securely. This will set limits on various XML signature constructs to avoid conditions such as denial of service attacks.

When not set, or set to false, the property instructs the implementation to process XML signatures according to the XML Signature specification without any special limits.

If a SecurityManager is enabled, the property is set to true by default.

Java API Documentation Updater Tool

To address CVE-2013-1571, users hosting publicly facing Java API Documentation generated with javadoc 5u45, 6u45, 7u21 or earlier are strongly encouraged to re-create the Java API documentation using javadoc from 7u25 or above.

Alternatively, for convenience of users and for those who have further modified the generated documentation, Oracle provides the Java API Documentation Updater, a repair-in-place tool.

Source code is available with the download if you have a non-standard environment. The Java API Documentation Updater Tool is a separate download and not included in any JDK/JRE bundles. Please also see important information related to the javadoc tool in the Known Issues section.

Help for Security Dialogs

A More Information link is added to the various security dialogs that may pop up prior to launching an applet or Java Web Start as a means for the user to get more information about the dialog.

Change in Networking API Implementation on Windows platforms

The implementation of the networking APIs has been changed on Windows to use the SO_EXCLUSIVEADDRUSE socket option by default. This change is necessary to address anomalies that arise when using both IPv4 and IPv6 applications that require to bind to the same port.

This change may cause issues for applications that rely on the ability to have multiple processes bound to the same address and port. When such issues occur, then use sun.net.useExclusiveBind system property as a temporary workaround to restore legacy behavior.

Changes to Runtime.exec

On the Windows platform, the decoding of command strings specified to java.lang.ProcessBuilder and the exec methods defined by java.lang.Runtime, has been made stricter since JDK 7u21. This may cause problems for applications that are using one or more of these methods with commands that contain spaces in the program name, or are invoking these methods with commands that are not quoted correctly. For more information see JDK 7u21 Release Notes.

In JDK 7u25, the system property jdk.lang.Process.allowAmbigousCommands can be used to relax the checking process and may be used as a workaround for some applications that are impacted by the stricter validation. The workaround is only effective for applications that are run without a security manager. To use this workaround, either the command line should be updated to include -Djdk.lang.Process.allowAmbigousCommands=true or the java application should set the system property jdk.lang.Process.allowAmbigousCommands to true.

Quoting and escaping commands on Windows platform is complicated. The following examples may be useful to developers if they are impacted by the stricter validation.

Example 1: The application needs to be launched with C:\Program Files\foo.exe.

Here are 3 possible ways:

    Process p = new ProcessBuilder("c:\\Program File\\foo.exe").start();
Process p = Runtime.getRuntime().exec(new String[] { "c:\\Program File\\foo.exe" });
Process p = Runtime.getRuntime().exec("\"c:\\Program File\\foo.exe\"");
    

Where it is not possible to change the application to use one of the above approaches, then the system property jdk.lang.Process.allowAmbigousCommands may be used as a workaround.

Example 2: The application needs to launch "dir > dir.out".
This case requires launching cmd.exe, and also it needs the output to be redirected to a file. The best approach is to use the ProcessBuilder as shown in the following example:

Where it not possible to change code to use ProcessBuilder or redirectOutput, then the following approaches can also be used:

Example 3: The application wants to launch a command with parameters that require special quoting; for example "log.bat \">error<\"".
Here are 3 possible ways to do this:

    Process p = new ProcessBuilder("cmd", "/C", "log.bat", ">error<").start();
Process p = Runtime.getRuntime().exec(new String[] { "cmd", "/C", "log.bat", ">error<" })
Process p = Runtime.getRuntime().exec("cmd /C log.bat \">error<\"");

Bug Fixes

This release contains fixes for security vulnerabilities. For more information, see Oracle Java SE Critical Patch Update Advisory.

Area: deploy/plugin
Synopsis: In-consistent behavior with remote/local policy file with ALL permission.

Both signed and unsigned applets with local or remote policy files with ALL permissions were not behaving as expected.

The behavior was due to honoring JCP security levels. The following summarizes the expected behavior:

• All applets and applications will show security warning dialog (unsigned/signed/signed-sandbox) even when there is a local/remote policy file with all_permissions.
• All applets and applications will honor all levels of security slider even when there is a local/remote policy file with all_permissions.
• A local or remote policy file should only effect execution of applets and applications i.e. to provide proper set of sandbox permissions at the time of execution as per policy settings.

Area: security-libs/java.security
Synopsis: Improve on checking order

The implementation of java.security.AccessController.doPrivileged(PrivilegedAction, AccessControlContext) and AccessController.doPrivileged(PrivilegedExceptionAction, AccessControlContext) have been modified to improve security.

Specifically, if a security manager is installed, the AccessControlContext is not created by system code and the caller's ProtectionDomain has not been granted the security permission (java.security.SecurityPermission) createAccessControlContext, then the action is performed with no permissions.

Area: core-libs/java.util.logging
Synopsis: Remove the stack search for a resource bundle for Logger to use

The java.util.logging.Logger class no longer does stack walk search for a logger's resource bundle. The stack walk search was intended as a temporary measure to allow containers to transition to using the context class loader and was specified to be removed in a future release. It will use the thread context class loader (if not set, use the system class loader) to look up the resource bundle and, if not found, it will fall back to use the class loader of the caller class that creates the Logger instance (via the Logger.getLogger() and Logger.getAnonymousLogger() method with a given resource bundle name).

If applications have not transitioned to use the thread context class loader as specified in the Logger class specification and depend on the temporary stack walk search behavior, java.util.MissingResourceException exception will be thrown if it fails to find the resource bundle.

The workaround is to set a system property, -Djdk.logging.allowStackWalkSearch=true, at the command-line to enable the stack walk search. This workaround is also temporary and will be removed in a future 7 update release. It is strongly recommended for applications to transition and remove the dependency on the stack walk search.

Known Issues

Area: tools/javadoc
Synopsis: Regression: Javadoc i18n regression

Problem:

If a package name contains non-ascii characters, the 'Frames' links on a package-summary.html page loaded in the main pane of a frames layout will load the overview-summary.html page rather than reload the package-summary.html page.

Work-around:

1. Do not use the 'Frames' links of a package-summary page already loaded in the main pane.
2. To get back to the package-summary page, click the desired package name link in upper left pane, then click the package name link in the lower left pane.