Today, Oracle released an update for Java 7 that addresses a security flaw found a few days ago and which is currently being exploited. Those who have Java installed and need it should update to it by going to www.java.com and installing it from there.
This is the fourth major security fix release in the last five months for Java 7. This latest fix addresses a flaw that exists all the way back into Java 6 and possibly earlier. This and other problems have led many security experts to call for Java to be simply removed from everything that you run.
It’s not that simple.
Advice for Home Users: Update to new, uninstall old versions
For those at home, it might be feasible. There is far less online that uses Java than there used to be thanks to Flash (which has its own history of security problems) and newer versions of HTML. If you remove it and you need it again later, it’s easy enough to reinstall. While versions from around Java 6 build 15 effectively remove older versions from about Java 6 build 10 and later, I do encourage home users to look in Programs and Features (Windows Vista and 7) or Add/Remove Programs (Windows XP) for versions older than the most recent version and remove them if found. For almost all home users, such older versions are not necessary.
Enterprise Admins: Careful…
But for enterprise users, it’s not that simple. In fact, the issue can become extremely complex. Many pundits, journalists, and even security professionals are saying the same thing: Remove Java from everything!
Not so fast. If you follow that blindly, you may find yourself out of a job because you took an intentional action that unintentionally broke the company. It doesn’t matter how good your intentions are when you’ve prevented people from filling out their timesheets, administering the phone system, or filing their expense reports. The time to recover from this can be substantial: writing a script to uninstall everything Java is not hard, but reinstalling all the versions required for every app can be extremely difficult and time-consuming.
I’ve seen scans of some systems that found Java versions back to 1.3 installed, much of it in active use. I’ve heard of even worse elsewhere, with some applets for much older software requiring Java 1.2. Some of these versions haven’t been supported for a long time. Here are the dates when support ended for each version:
- Java 5.0 (aka 1.5): October 2009
- Java 1.4: October 2008
- Java 1.3: December 2006
Since these times, there have been no public security patches for these products and they remain vulnerable to published exploits, not to mention not having current protections. But there exists a mechanism in the Java language to require (or at least request) a specific Java version. For example, a Java applet might go looking for Java 1.5 build 12. It’s a consequence of old design decisions when the compatibility from one build to the next could be shaky, so Java developers would write for a specific version of Java. This is at least as bad as writing for specific versions of Internet Explorer, except that older versions of IE actually get patched.
Here’s the catch, though: if a legitimate Java applet can do it, so can a malicious one. And I’ve seen it happen many times. But Java developers that locked into Java 5 (or 1.4 or 1.3) and then never updated their applets have cursed enterprises to keep vulnerable software on their systems, often widely spread, leaving them very vulnerable. (If this is you, please, for the love of all that is good and right, update your applets. Even if it costs a bit, you will build up goodwill among customers and security professionals. And I’ll buy you a drink if we ever meet.)
Advice for Enterprise Admins: Remove what you can, update the rest
I wish I could give enterprise people a simple answer. Really, it comes down to this: audit your software and determine what’s actually needed. If it’s feasible to remove Java from a system (without someone screaming), great. By all means, go ahead and do it. But don’t do it without consulting with the users and the business process owners. Work with them to see if something newer can be used. Offer to set up a test system to see if it will work with a newer version (more recent versions of Java are sometimes more tolerant to older applets) and arrange a migration schedule if it works. If it doesn’t work, see if it’s feasible to move the applet off to a system that doesn’t see much Internet use such as an internal Terminal Server or Citrix Server and then remove it from other internal systems. In any case, try to work with the applet vendor to see if it’s possible to use a newer Java engine. It doesn’t hurt to ask.
Of course, it’s also possible that you just need to keep them all in place. All I can suggest there is to review your security architecture and, working with the vendors if necessary, configure IDS/IPS signatures, firewall and/or proxy rules, and antimalware settings to watch for attacks against the older versions. It won’t be perfect, but it may be the best you can do until the applets are no longer needed.