It’s time to run Java out of town

I’ve been railing about Java for years, but enough is enough. Java exploits top all other infection vectors, on any platform, year after year. Oracle has shown repeatedly that it’s organically incapable of keeping the Java Runtime Environment secure. If your company makes Java apps, either for internal use or for release to an unsuspecting world, it’s time to stop. If your clients are using Java, it’s time to give them the tools and the support they need to block Java.

Java’s done. Put a fork in it.

No doubt you’ve heard about the Flashback Trojan/virus. You might not have heard that Kaspersky now has hard, cold details on 670,000 infected Macs — that isn’t an estimate, it isn’t an extrapolation, it isn’t some sky-is-falling scare tactic. The folks at Kaspersky have ID numbers for 670,000 Macs that are actively participating in the Flashback botnet.

Windows users shouldn’t be feeling complacent or smug. The Java holes used to infect those Macs also appear in Windows versions of Java. We just dodged the bullet this time because the Flashback author(s) decided to pick on Macs.

There’s a lot of misinformation floating around about the nature of the Flashback onslaught. Flashback started out as a Trojan last September. It tricked Mac users into installing the Trojan by disguising itself as an update to Flash.

Sometime in February, the Flashback author(s) then upgraded their infection routines to take advantage of old Java security holes, ones that were patched in 2009 and 2011. Intego describes this February variant, Flashback.G, as a three-way infector. If you use Safari and go to an infected site, and you have Java enabled but one of the old Java security holes hasn’t been patched, you can get hit with a drive-by infection — you don’t need to lift a finger and your Mac gets pwned. If the Flashback.G infector finds that you have installed both of the old Java patches, it simply asks if it’s OK to install the payload. The Mac installation dialog box says the content is signed by “Apple Inc” but “the digital signature of this certificate could not be verified.”

By and large, Windows users are savvy enough to walk away from a warning like that. But many Apple users aren’t quite so experienced, or damaged, or inured. Many of them took the bait.

Now you understand why some places say Flashback is a Trojan and others identify it as a virus. In fact, it’s both.

The big brouhaha this past week involves yet another refinement of the Flashback infector, generally identified as Flashback.K to Flashback.N, depending on whose numbering system you follow. This variant takes advantage of a relatively new drive-by hole in Java, identified as CVE-2012-0507. Prior to April 3, if you were using Safari and had Java enabled on your Mac and you ventured to an infected website, your machine got taken. No questions asked.

On April 4, Apple issued a patch for Java that was supposed to block this latest Flashback infection vector. Apparently it didn’t cover all the bases because Apple issued a second patch on April 6. Apple was widely criticized for dragging its feet on this patch because Oracle had patched the same hole for Windows users back on Feb. 17. Apple’s facing even more criticism because the patch only works on OS X Snow Leopard or Lion. If you’re running an older version of Mac OS, such as Tiger or Leopard, your tail’s hanging in the wind.

Apple doesn’t bundle Java with any of its products any more — and hasn’t done so since OS X Lion — but many Mac owners find themselves installing Java manually when they go to a website that requires (or requests) Java.

Oddly, Flashback doesn’t even try to infect Mac systems with antivirus products Little Snitch, Virus Barrier, iAntiVirus, Avast, ClamXav, HTTP Scoop, or Packet Peeper installed. And it won’t infect Macs that have Apple’s free Xcode development environment installed.

If you want to see whether your Mac is actively participating in the Flashback botnet, go to the Kaspersky verification site and run your UUID through its lookup routine.

The Flashback payload appears to move in two directions. First, it scrapes log-in IDs and passwords from the Safari browser. Second, it redirects search engine results.

Security researcher Brian Krebs has been recommending for years that people turn off Java and enable it only when they absolutely have to run it. Many sources peg Java as the primary source of Windows infections over the past two years, including this Virus Bulletin 2011 presentation and a Virus Bulleting analysis of infections delivered by exploit kits.

One way to protect your computer is to use two different browsers — one with Java enabled, the other without — and only haul out the Java-jinxed browser when absolutely necessary. The other approach is to uninstall or disable Java in the browser you use and reinstate it only when you have no other options.

The easiest way I’ve found to manage Java is through the NoScript add-in for Firefox — in fact, that’s the primary reason I use Firefox as my main browser for both Windows and Mac. If you prefer Chrome, disabling Java takes only a few clicks. Instructions for disabling Java in Internet Explorer or Safari — or allowing Java (to support, say, OpenOffice) but disabling it in the browser, are availabe on the Microsoft and Apple sites.

But that only treats the symptoms. To get rid of Java as the world’s foremost computer infection vector, we simply have to get rid of Java. Yes, it’s installed on 3 billion computers. Yes, many companies rely on Java — just as they relied on ActiveX technology not so long ago. The lamentable fact is that Java’s rotten to the core, and Oracle’s done nothing to improve its trustworthiness. IT departments need to get on the bandwagon and run Java out of town.

Steve Jobs dumped Java for good reason.

This story, “It’s time to run Java out of town,” was originally published at InfoWorld.com. Get the first word on what the important tech news really means with the InfoWorld Tech Watch blog. For the latest developments in business technology news, follow InfoWorld.com on Twitter.