Why you can’t dump Java (even though you want to)

Java’s direct responsibility in the recent Mac Flashback Trojan attacks have many calling for Java’s retirement, including InfoWorld’s own Woody Leonhard.

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.

[ Also on InfoWorld: Woody Leonhard makes the case for dumping Java. Do you agree? | InfoWorld’s expert contributors show you how to secure your Web browsers in this “Web Browser Security Deep Dive” PDF guide. | Keep up with key security issues with the Security Central newsletter. ]

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.

It’s easy for some of us to say, “Hey, let’s get rid of Java.” But I bet the businesses that require and need it are equal in number to those that are able to abandon it.

Java flavor of the month I’m not someone who jumps on on the “throw this program out” bandwagon, for a few reasons. If we got rid of Java, the same problem (computers exploited using popular software) would come back to haunt us in a different form. Five years ago, most Internet exploits came through Internet Explorer, which is no longer true. A year or so ago, it was Abobe Acrobat PDF exploits or Adobe Flash Player exploits. This time it’s Java.

Another bigger lesson I hope readers understand: Security sandboxes don’t work when they become popular (see the Grimes hacking popularity corollary). Java was created in 1995 by James Gosling and Sun Microsystems. It was built from the ground up with security as a pillar. It’s integral to the language and its runtime environment. Very smart people contemplated the problems that could occur and created offsetting security solutions.

For all their good intentions, it didn’t work. Java has always been among the most successfully exploited software from the beginning. It turns out the security sandbox — all security sandboxes, for that matter — aren’t so safe once hackers turn their attention to them.

Many vendors send me their security sandbox products for review, and I always turn them down. Why? While they temporarily increase security, none would withstand the passage of time if they became popular. How do I know? Because all popular security sandboxes made since the beginning of computers have fallen. Show me one popular security sandbox that didn’t fall.

The real failure A good recent example is the Google Chrome browser’s security sandbox. Google Chrome and its security sandbox offer a great design and idea. Their framework should make them the most secure browser, yet the Chrome browser has suffered hundreds of found security exploits since it came out in September 2008. It has more found exploits than its competitors, and more often than not, those exploits lead to complete system compromise.

I’m not trying to pick on Google Chrome. Whatever becomes popular gets exploited most. Google Chrome, even with its hundreds of known vulnerabilities, does not get exploited as much as Internet Explorer or Firefox.

The lesson is that an application using a security sandbox does not equal better security. Don’t get me wrong, sandboxes help — just like antimalware scanners help. They reduce security risk, but they are in no way a panacea.

The bottom line is that we aren’t addressing the real problems. It isn’t a security bug here and there in a particular piece of software; that’s a problem we’ll never get rid of. Instead, we allow almost all cyber criminals to get away with their Internet crime without any penalty. They almost never get caught and punished. Until we solve the problem of accountability, we will never get rid of the underlying problem.

Getting rid of Java certainly won’t fix that.

This story, “Why you can’t dump Java (even though you want to),” was originally published at InfoWorld.com. Keep up on the latest developments in network security and read more of Roger Grimes’ Security Adviser blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.