• United States




What the latest Java flaw really means

Jan 15, 20136 mins
Data and Information SecurityJavaMalware

As the firestorm around the zero-day Java flaw swirls higher, here's what you need to know -- and do -- about this extraordinary threat

The latest Java zero-day flaw has the tech world in an uproar. This newest hole, actively exploited in the wild, was patched by Oracle yesterday — only to have multiple ultratrusted security gurus saying Oracle didn’t address every bug and some even maintaining it could take Oracle two years to fix all the vulnerabilities.

You know it’s a bad day at Oracle when the Department of Homeland Security says this:

This and previous Java vulnerabilities have been widely targeted by attackers, and new Java vulnerabilities are likely to be discovered. To defend against this and future Java vulnerabilities, consider disabling Java in web browsers until adequate updates are available.

[ Also on InfoWorld: Java security comes down to ‘war of attrition’ | Find out how to block the viruses, worms, and other malware that threaten your business, with hands-on advice from expert contributors in InfoWorld’s “Malware Deep Dive” PDF guide. | Keep up with key security issues with InfoWorld’s Security Central newsletter. ]

Java exploits are nothing new — although this one got so much media coverage that my mother called to ask me how to uninstall Java after watching the morning news shows. I tried to assure her that she didn’t need to panic, but apparently she takes Matt Lauer’s word over mine.

How much of the threat is hype and how likely is this to be yet another touted “huge attack” that fizzles away into nothingness? Read on.

The sad Java security tale Installed on over 1.1 billion desktops and 3 billion mobile phones, Java is the world’s biggest target for hackers. It has been the top exploit vector for Web browsers for many years. Ask anyone involved with detecting and eradicating malware in the enterprise; Java, they will say, is responsible for most of it.

Java’s vulnerability has always saddened me because Java was the first superpopular language built from the ground up with security in mind. It wasn’t an afterthought. The developers foresaw how Java might be abused and locked it down with a set of rules, security checks, and a security sandbox.

Ultimately, three details killed the security promise of Java: First, the original security model was too secure. It was so locked down that legitimate developers couldn’t take care of normal tasks, like allow you to save a file to your desktop. Java had to scrap the security model and evolve to a scheme that balanced security and functionality.

Second, Java has lots of moving parts, including a virtual machine, runtime engines, type verifiers, bytecode compilers, a security sandbox, garbage collectors, and so on. This means that Java is complex, and security and complexity seldom go well together.

Third, Sun and Oracle have piled on new functionality to keep Java competitive. Every time a new capability is added, a new attack vector appears for hackers to explore.

What do I do now? A common refrain among security experts is to tell people to uninstall or disable Java if they don’t need it. That’s still good advice, especially for older versions. Unfortunately, Java is required to run not just small programs and games, but also mission-critical enterprise applications.

Bu there’s a difference between the Java that runs in your browser and Java that can run on your desktop computer, phone, or server. The JVM (Java Virtual Machine) allows Java applets to run within a browser. The JVM is a subcomponent of Java, which is a complete language and development environment.

Most security exploits target specific JVM versions and may not work on Java running alone on a desktop. On the other hand, Java exploits may target Java beans or Java servlets — but in general, server-side threats appear to be rarer. Not every Java exploit is equally threatening; it depends on which Java component is installed and what the exploit does.

In the latest case, Java exploit CVE-2013-0422 impacted Java’s Runtime Engine (JRE), which means that most of those 1.1 billion desktops are vulnerable. Several sources (including Symantec) found that the zero-day exploit was included in several widely sold malicious hacker exploit kits.

If you need Java, keep it patched — you’ll be far ahead in the game and significantly reduce risk. I’ve yet to see Java appropriately patched in any environment. None — not a single one, even those companies that think (and say) they have patching under control. If you want to patch Java correctly in the enterprise, it’s probably going to take a specialized project team with the backing of senior management. Without those requirements, you’re going to fail and the exploits (most of which would be blocked by patches) will continue to take down your computers.

How scared should you be? Is this Java exploit the one we should really be afraid of? Will it go around the world and quickly infect everyone like MS.Blaster or SQL.Slammer?

The heightened global publicity this flaw has received will ensure many hackers will pursue exploits. Plus, serious white hat hackers, including H.D. Moore and Dave Aitel, have confirmed that additional bugs still exist after the latest Oracle patch — and point to Java as a more reliable exploitation vector than the browser hosting it.

But the major obstacle that prevents Java exploits from becoming superfast-spreading worms is that they almost always require client-side user interaction to infect a computer. The world’s fastest worms and viruses self-replicate; once launched by a single person, they could infect an entire network or a whole enterprise. Java exploits, on the other hand, usually work machine by machine, with each activation exploiting only one computer. This factor by itself almost guarantees that Java exploits will not tear across the world like the infamous worms of the past.

On the other hand, the sheer ubiquity of Java could result in very high infection rates at a more leisurely pace. Java is everywhere, and enterprises can’t uninstall or disable it.

Ultimately, no one can predict which malware programs will go nuclear. Each year dozens have that potential. But for every Nimda, Codered, Iloveyou, or Conficker, there are millions of similar exploits you never heard of. Why one malware program takes off in popularity while its twin lies dormant has always been a mystery to me (and every other antimalware researcher). If we could predict which Trojan or worm would go nuclear out of the tens of millions of rogue programs released each month, our antivirus programs would be a lot faster and their definition databases a lot smaller.

Nonetheless, this latest zero-day exploit could be Java’s tipping point. Already, every company I’ve talked to in the last few months wanted to remove Java because of its nearly constant exploitation. They may not be able to get rid of it, but they’re talking about it. Oracle needs to do something dramatic or it could find Java washed away in a storm of protest.

This story, “What the latest Java flaw really means,” was originally published at Keep up on the latest developments in network security and read more of Roger Grimes’ Security Adviser blog at For the latest business technology news, follow on Twitter.


Roger A. Grimes is a contributing editor. Roger holds more than 40 computer certifications and has authored ten books on computer security. He has been fighting malware and malicious hackers since 1987, beginning with disassembling early DOS viruses. He specializes in protecting host computers from hackers and malware, and consults to companies from the Fortune 100 to small businesses. A frequent industry speaker and educator, Roger currently works for KnowBe4 as the Data-Driven Defense Evangelist and is the author of Cryptography Apocalypse.

More from this author