The latest Java zero-day hole ascended to the level of a national security threat. Has the tipping point for Java finally come?

Why the Java threat rang every alarm

By InfoWorld Tech Watch
Created 2013-01-18 03:00AM

If the IT industry had a color-coded threat-level advisory system, the alerts would have spiked to red this week -- and in a way they did when the Department of Homeland Security, no less, urged users to disable or uninstall Java [1] because of a serious security vulnerability.

Judging by the ensuing avalanche of ink (mea culpa for adding to the pileup), you might think this attack took the industry by surprise. Far from it -- as Twitter engineer and security expert Charlie Miller told Reuters [2], "It's not like Java got insecure all of a sudden. It's been insecure for years." Java was responsible for half of all cyber attacks [3] last year in which hackers broke into computers by exploiting software bugs, according to Kaspersky Lab, and diatribes against Java -- many on the pages of InfoWorld -- have been going on for years.

What was it about the latest zero-day [4] that unleashed such a fevered pitch of concern that even NBC's "Today" show took up the cry? Has Java finally reached its tipping point?

As InfoWorld's Galen Gruman writes in "How to kill Java dead, dead, dead [5]," the fact that the feds have gotten into the act speaks to the rising threat of a global cyber war:

In an era where the United States and Israel have launched a quiet cyber war against Iran [6] and others with worms like Stuxnet, and Iran has counterattacked by trying to take down U.S. banks' websites, it won't be long before Java is used like the lax airline security was on 9/11 to make something really bad happen.

Hackers are using holes in Java to sabotage computers that run key business processes at banks, utilities, and government agencies. Unfortunately, as Gruman points out, "If Java went away tomorrow, many banking and e-commerce websites would cease to function, as would many electronic medical records systems and tons of specialty Web apps, from building inspector reporting tools to online voting."

By virtue of its sheer pervasiveness, the operational risk that Java presents is growing into something of a Y2K issue for businesses. InfoWorld's security blogger Roger A. Grimes [7] goes so far as to say that "every company whose security I've audited has a Java problem -- an ongoing one that long predates the current threat. Java provides a convenient attack vector for most of the malware arriving in companies -- and not just the annoying stuff, but advanced persistent threats, money stealers, and more."

Why haven't companies kept up with patching Java? It's not just old-fashioned sloth or incompetence to blame. Grimes says, "It's the number of mission-critical enterprise apps tied to specific Java versions. In case after case, IT security people say they can't patch Java in a more timely manner because doing so breaks too many vital applications." While they're waiting for Oracle to just finally, gosh-darnit fix the thing already, "unpatched Java is wrecking havoc across the enterprise."

Oracle may be an easy scapegoat for users' frustration, but InfoWorld's open source blogger Simon Phipps explains why it could take a very long time to fix Java [8]. Its vulnerability "devolves not to one issue, but to a series of issues, one knocking into the other like dominoes. Oracle has fixed one of the dominoes with a patch, but there are likely to be other ways to tip over the entire row." One more such domino fell just yesterday, when a security firm revealed that many apps using the popular open source Spring Framework are vulnerable to a type of remote-code injection [9] because of a flaw in -- you guessed it -- Spring's soft Java underbelly. Cue shades of the many-headed Hydra from Greek mythology.

The nature of the Java problem is thorny and many-sided, but the underlying question remains: How to get away from our dependency on Java? InfoWorld's Woody Leonhard lays out excellent step-by-step instructions for how users can immediately disable Java in their browsers [10]. But as Gruman observes, users aren't the real problem -- businesses are. Ultimately, the security ball is in enterprise IT's court, and as Grimes rightly highlights, this issue needs to become a top company priority:

If you are tired of unpatched Java being a continuing unresolved problem, if you are tired of business units always pushing back saying you can't upgrade Java because it will break their apps, don't politely ask them anymore. ... Show them how Java is the No. 1 problem and causing the most risk. ... In most companies, senior management has no idea that Java is their No. 1 problem. I'll go further: In most companies, most of the IT security staff doesn't understand that Java is their No. 1 problem. How can you expect to solve your problems if the senior managers involved and the worker bees don't understand the risks and threats?

After this latest bout of collective hand-wringing is over, maybe enterprises and vendors alike will wake up to the risks. Gruman suggests one step in weaning our current operating systems and apps off Java is for the feds to designate non-Java-free operating systems as noncompliant with security standards for gaining or renewing government contracts. "Loss of income is the motivation that vendors and developers need," he writes.

Hit 'em in the bottom line. We can't afford to tolerate the Java problem anymore.

This article, "Why the Java threat rang every alarm [11]," was originally published at InfoWorld.com [12]. Get the first word on what the important tech news really means with the InfoWorld Tech Watch blog [13]. For the latest business technology news, follow InfoWorld.com on Twitter [14].

Application Development Oracle Java Programming Hacking Security Management Security Standards Vulnerability Assessment Web Security Security


Links:
[1] http://www.kb.cert.org/vuls/id/625617
[2] http://www.reuters.com/article/2013/01/14/us-java-oracle-security-idUSBRE90D10P20130114
[3] http://www.chicagotribune.com/business/sns-rt-us-java-oracle-securitybre90c0jb-20130113,0,5622241.story
[4] http://www.infoworld.com/d/security/java-zero-day-prompts-renewed-calls-disable-210658
[5] http://www.infoworld.com/t/java-programming/how-kill-java-dead-dead-dead-210860
[6] http://www.computerworld.com/s/article/9227670/Report_Obama_ordered_Stuxnet_attacks_on_Iran
[7] http://www.infoworld.com/t/vulnerability-assessment/just-patch-java-easier-said-done-210973
[8] http://www.infoworld.com/t/java-programming/why-fixing-the-java-flaw-will-take-so-long-210946
[9] http://www.infoworld.com/d/security/major-flaw-in-java-based-spring-framework-allows-remote-code-execution-attackers-211066
[10] https://www.infoworld.com/t/web-browsers/how-disable-java-in-your-browsers-210882
[11] http://www.infoworld.com/t/mobile-platforms/google-android-22-progress-or-more-platform-fragmentation-676?source=footer
[12] http://www.infoworld.com/?source=footer
[13] http://www.infoworld.com/blogs/infoworld-tech-watch?source=footer


Comments

Popular posts from this blog

Report: World’s 1st remote brain surgery via 5G network performed in China

Visualizing The Power Of The World's Supercomputers

BMW traps alleged thief by remotely locking him in car