What you should know about Secure Static Versioning
Sun recently released a Java security advisory titled Java Plug-in and Java Web Start May Allow Applets and Applications to Run With Unpatched JRE. As with any security advisory, it's important that you take note and ensure that your software is up-to-date -- in this case, the problem is fixed in Java 1.5.0_06 or higher. But a blog entry by the Washington Post's Brian Krebs raises some concerns about this particular security advisory and suggests that merely patching your machine may not be enough.
The security advisory admittedly wasn't very clear on this point, but if you have Java 1.5.0_06 or higher installed (which I imagine most of you do by now), you are in no danger from this issue, even if you also have older versions of Java on your system. While that's obviously good news, the fix for this issue may have an impact on some Java developers. If you deploy Java applets or unsigned Web Start programs, keep reading.
Java has always allowed you to keep multiple versions installed on the same computer at the same time. Whether you love this particular feature or hate it, there's no denying that it can be useful at times. Certainly as a developer I appreciate being able to have Java 5 and Java 6 on the same machine at the same time, and I know enterprises prefer to be able to certify their internal software against exactly one version of Java without worrying about employees accidentally changing the Java version out from under them.
But as with all significant decisions, there is no single right answer. What's right for developers and enterprises isn't necessarily as great in the consumer market, where users would generally prefer not to leave old versions of the software lying around after an upgrade. Unfortunately we can't just suddenly start removing older versions -- because Java has always worked this way, many programs depend on this behavior. They may take the Java VM's location and "burn it in" to their launch scripts or registry entries, and removing the specific version on which a program depends would then cause it to break. Various ideas on breaking out of this vicious cycle have been tossed around, but for the time being, this is just the way things work.
Unfortunately, it also led to a security hole (again, fixed in Java 1.5.0_06).
Sun has always responded promptly to any security problems with Java, quickly releasing a patched version which fixes the problem. But since the previous unpatched and unsafe versions have been left on your hard drive, a malicious program could potentially get access to them. Theoretically, a Java applet could have requested a specific older version of Java and used a known (and long-since patched) security hole in it to compromise your system, even though you had dutifully downloaded the security update. Clearly, this was a situation that had to be addressed.
The solution is what is known internally as Secure Static Versioning. Basically it boils down to "untrusted code can't use unpatched older versions of Java". Previously, if you had several versions of Java installed on your system, a program could request one of the older versions in order to exploit it. Now, no matter which version of Java an untrusted program requests, it will receive the highest installed version. The practical upshot of this is that untrusted code will always be run in the most secure Java environment available.
Signed, trusted Web Start programs are allowed to request whatever version of Java they want -- they're trusted, so they have full access to your system anyway. Applets (even if signed) will always be run in the latest version. The discrepancy is due to technical differences between Web Start and the Plug-In; I'll go into the details in a future entry.
With the quick overview out of the way, let me sum up in an FAQ:
1. How much danger am I in?
If you have the latest JRE (1.5.0_06 or later) installed on your system, none at all. All current JREs include the Secure Static Versioning change, so applets and sandboxed Java Web Start programs are unable to access older versions of Java.
If you don't have Java 1.5.0_06 or higher, you would be wise to go ahead and install the latest version. I'm not aware of any exploits "in the wild", but it certainly doesn't hurt to be safe.
2. Do I need to remove old versions of Java?
No. Applets and sandboxed Java Web Start programs aren't allowed to access older versions of Java. They don't pose any threat in the first place, so removing them won't change anything. If you do decide to remove older versions of Java, you need to be sure that none of the applications on your computer are using them first.
3. Do I have to change anything about my Java programs?
No. If you have a Java applet or sandboxed Java Web Start program, it will always run in the latest available version of Java without any changes on your part. As long as you test your software against newer versions of Java, you shouldn't encounter any problems.
4. What does this mean for standalone Java programs?
Nothing. Just like native programs, Java programs which run outside of the Java sandbox already have full access to your system. Requiring them to run in the latest version of Java wouldn't do anything to increase security.
So, that's that. What might have sounded like a scary security issue (OMG YOU NEED TO UNINSTALL JAVA!!!!11!!!1) turns out to be quite mundane: install the latest patch release of Java and you're completely safe. This is of course great advice no matter what software we're discussing -- you are running with all of the latest patches for your operating system, web browser, Flash Player, and everything else on your system, aren't you?
Oh, and while we're on the subject of updates...
If you update using Java Update, rather than downloading via java.sun.com, you may find that you don't end up with the very latest update release. That's normal, and it's a result of the fact that Sun distinguishes the latest "consumer version" of Java from the latest "developer / enterprise version". If you go to java.sun.com, you get the latest developer / enterprise version, which is the very latest and greatest code available. If you go to www.java.com or use Java Update, you end up with the latest consumer version, which might be a couple of update releases behind the developer version (but is otherwise identical).
In order to avoid swamping end-users with too many updates, only two or three versions of Java a year are made available as consumer versions. Naturally, security fixes (such as the one under discussion here) always warrant a new consumer version, so you're safe no matter how you choose to update your copy of Java.