Java SE 7 Update 25 – Release-Notes explained.

Markus EiseleJune 21st, 2013Last Updated: June 20th, 2013

0 37 4 minutes read

Yesterday was CPU day. Oracle released the Java SE update 25 with the June Java Critical Patch Update. After the last major update in April this is the last one which does not fit into the Oracle Critical Patch Update schedule along with all other Oracle products. Starting in October 2013, Java security fixes will follow the four annual security release cycle. But don’t panic: Oracle will retain the ability to issue emergency “out of band” security fixes through the Security Alert program. Further on this is the first CPU which will not publicly update the Java SE 6 family. If you need an update on that JRE Family you need to have a Oracle’s Java SE Support. Going down this road brings you Java SE 6u51.

The Management Summary

This release has been announced some time back already and addresses 40 vulnerabilities with fixes across Java SE products. 37 of these vulnerabilities may be remotely exploitable without authentication, i.e., may be exploited over a network without the need for a username and password. Four of them are applicable to server deployments (CVE-2013-2451,CVE-2013-2457, CVE-2013-2407, CVE-2013-2461). A complete list is shown in the Oracle Java SE Risk Matrix.

I’m an End-User. Whats new?

Not very much this time. Two little improvements which should not impact you too much.

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. These online checks might not work at all in enterprise environments or have an impact on startup performance. To avoid both it is now possible to disable it. You should carefully make this decision and only do it in managed environments because it decreases the overall security protection mechanism.

Further on the security dialogues have been enhanced with a “more information” link. Whenever you hit an insecure constellation you are now presented with the warning dialogues introduced with 7u21 with an additional link in them.

If you haven’t been prompted to update you should do this as soon as possible. Download the JRE for your system from java.com and be up-to-date!

I’m a Developer! Tell me the dirty news!

No dirty and not announced news this time. But again, you still have a couple of things to take care of. First of all this release brings the new Olson Data 2013b. Which is a good thing even if we have the TZUpdater back.

An important bug was fixed regarding signed jars. With 7u21 signed jars were allowed to be loaded without any unsigned warning if they contain unsigned index.list entry but this is not true anymore with 7u25. To properly sign a jar, index entries must be created before the jar is signed. For more information see bug 8016771.

JDK 7u25 release introduces the permissions and codebase attributes in the JAR Manifest File. The Permissions attribute is used to verify that the permissions level requested by the RIA when it runs matches the permissions level that was set when the JAR file was created. The values sandbox and all-permissions are valid. It must match the permission level requested in the JNLP file or the applet tag.

The Codebase attribute is used to restrict the code base of the JAR to specific domains. Set this attribute to either the domain name or IP address where the application is located. A port number can also be included. For multiple locations, separate the values with a space. An asterisk (*) can be used as a wildcard only at the beginning of the domain name. The value of the Codebase attribute must match the Code base specified in the JNLP file or the applet tag or the actual location from which the app is accessed.

If one of both or both requirements don’t match, an error is shown and the application is not run. If the attributes permissions or codebase are not present, a warning is written to the Java Console and the permissions/codebase specified for the applet tag or JNLP file is used. This behavior is most likely going to change and be handled more restrictively in the future. If you want more examples have a look at the SE 7 technote.

If you’re hosting Javadoc somewhere make sure to regenerate it with latest Javadoc Tool. As stated in CVE-2013-1571 API documentation in HTML format generated by the Javadoc tool that contains a right frame may be vulnerable to frame injection when hosted on a web server. If you can’t regenerate them, use the new Updater Tool which is NOT contained in the SDK/JRE bundles.

Since 7u21 the decoding of command strings specified to java.lang.ProcessBuilder and the exec methods defined by java.lang.Runtime, has been made stricter on Windows platforms. 7u25 brings a new system property jdk.lang.Process.allowAmbigousCommands which 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. 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.

Further on there have been a lot of bug fixes which directly address CVEs. A complete explained list is available in text form.