Why You Can't Dump Java (Even Though You Want To)
It's understandable. Unpatched Java is responsible for sizable proportion of today's successful Internet browser attacks, including two compromises I've suffered over the last couple of years. It's also been the culprit behind nearly every Windows exploit that's affected friends and family, aside from the pure social engineering exploits from phishing, Craigslist scams, and so on.
Those anecdotal experiences are backed up by good data. Microsoft's Security Intelligence Report 11 shows Java exploits are by far the biggest ongoing problem impacting monitored Windows computers. Java has been bedeviled by hundreds of security vulnerabilities over time. Go to any security vulnerability database and you'll see dozens of bug fixes each year since Java's creation in 1995. You'd be hard-pressed to find any single application that has hosted as many security bugs as Java.
Banishing Java: Easier said than done
Is it time for Java to go? Should we recommend that people disable or remove it? Like most problems in life, the answer isn't an easy yes or no.
One thing is certain: Any software not in use, including Java, should be removed from your system. That's common sense -- and a long-recommended security tenet. It reduces the attack surface for exploits and their creators.
But many enterprises live and thrive on Java -- both pure Java programs and runtime applets running in the browser. They can't remove it. Personally, I've removed Java a few times over the years, though many websites and services I love (like Secunia's Online Software Inspector) require Java. There are enough cool and useful services that depend on Java that I end up reinstalling it.
Sure, I could opt not to use those Java-enabled services or install Java and uninstall when I'm finished. But the core problem isn't necessarily Java's exploitability; nearly all software is exploitable. It's unpatched Java. Few successful Java-related attacks are related to zero-day exploits. Almost all are related to Java security bugs that have been patched for months (or longer).
Patch and patch again
Let's not forget that Apple's recent Trojan problems are a bigger problem than they should be because Apple didn't apply Java patches that were available for almost two months. Oracle's recent Java programs even have an auto-update feature that bugs people to update Java when a new version is available. Most people exploited by Java bugs have been ignoring that warning message for months. Patch better, and you'll have much fewer successful Java exploits, pure and simple.
Of course, better patching is not so easy. Java installers didn't uninstall older versions of Java even when a new version was applied. Many computers I've examined have two or more versions of Java running, and unfortunately, malicious code can query the visiting computer for its Java versions and run the one that the malicious code knows to be exploitable.
Many enterprises have applications that rely on an old Java version. I've done some security audits where the company tells me it must have three to five different versions of Java to run the business. In all likelihood, the company can probably get by with just one version, simply by testing all its Java apps (or applets) against the new versions or making a few small modifications to the older programs. But that never seems to be a priority, so some companies simply cannot get rid of old versions of Java with known vulnerabilities.