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
Source URL (retrieved on 2013-01-19 09:52AM): http://www.infoworld.com/t/security/why-the-java-threat-rang-every-alarm-211061
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
Post a Comment