Oracle released three updates to Java yesterday. It is important to note that they contain several security related changes. The majority of those changes have been announced since a while and first thing to notice is, that Oracle ships as planned.
Oracle’s Java Platform Security ManagerMilton Smith recently gave a talk at DevoxxUK titled “Securing the Future with Java” where he explains the overall process of handling security within Oracle’s products and also gave an overview about the Java CPUs. Those 4-monthly updates cover all Java families and according to this we also see a Java SE 6 Update 45 and a new Java SE Embedded 7 Update 21 since yesterday which addresses the same issues on that families.
What is in it for me? (I’m an end-user)
The release notes list a couple of new things. Most of them are targeted at a more secure Java runtime for end-users. Starting with the most important change, the low and custom settings on the Java Control Panel(JCP)’s Security Slider are now removed. That basically mean that unsigned applets don’t run without warning anymore. Further on, depending on the security level set in the Java Control Panel and the user’s version of the JRE, self-signed or unsigned applications might not be allowed to run at all. The default setting of High permits all but local applets to run on a secure JRE. If the user is running an insecure JRE (<7), only applications that are signed with a certificate issued by a recognized certificate authority are allowed to run.
As a brief guideline you, the end-user now see two different kind of Java warning messages in your browser after (!) you already agreed to starting the active content for which your browser typically asks you, too. All blue and Java is good and valid content (compare picture to the right “trusted and signed”). Applications of this type are typically low risk, but Oracle advises you to check that the app name, publisher name and location make sense given the site you are visiting (i.e. Java Detection, Oracle America, http://www.java.com while on java.com). It is recommend you hit Cancel if any of this information does not match or doesn’t make sense to you at all.
If you come across an unsigned or not validly signed application things start to get yellow and red (compare picture “Unsigned”). To make it short, you most likely are willing to revise your decision about executing this kind of applications. Even if there are different levels of potential security risks compared to self signed applications (Sandbox vs. Full Access) you should cancel and don’t run any application that generate a yellow/red warning for you! If you’re interested in the complete story you can dive into more details about “Java Security Prompts“.
Beside this very prominent change Oracle also introduced a central certificate and jar blacklist repository. This data is updated on client computers daily on the first execution of a Java applet or web start application. With this change your JRE is now able to call home and get the most up to date information about potentially bad certificates and 4th-party jars out there. Oracle didn’t disclose anything about the process behind it but I guess, that this mechanism will be used to block a majority (all) of the know exploit kits completely.
You get plenty of security fixes! There is a complete list available and it is called the “Oracle Java SE Risk Matrix“. This Critical Patch Update contains 42 new security fixes for Oracle Java SE. 39 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. 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!
What is in it for me? (I’m a developer)
If you’re working with Applets, JavaFX Applications in the browser or with Java WebStart applications you might want to change your development process to support signed applications. With the introduced changes it is most likely that no end-user is able to run your application when they are either self-signed or unsigned. For a detailed overview about what to do refer to the signing applets guide in the Java tutorials.
We now have a server JRE. If you need the JRE on a server and do not want the ability to run RIAs, download the Java SE Server JRE. This version of the Java SE Server JRE does not include the Java plug-in or Java Web Start support, additional tools might be removed from future versions.
Some behavior changes have been introduced also. The RMI property java.rmi.server.useCodebaseOnly is set to true by default. This might lead to broken RMI-based applications. Watch out for a stack trace that contains a java.rmi.UnmarshalException containing a nested java.lang.ClassNotFoundException.
On Windows platform, the decoding of command strings specified to Runtime.exec(String), Runtime.exec(String,String[]) and Runtime.exec(String,String[],File) methods, has been improved to follow the specification more closely. 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.
More Information
There is plenty of coverage in the official documentation for developers. The end-user documentation is also improving very quickly and a good place to start is java.com. For my German reads you can also find a more detailed coverage on heise.de/developer.
