The Death Of Java In The Enterprise?

An early January Java zero-day bombshell has been just the inauspicious start to 2013 that many security researchers needed to set off talks again about the future of Java as a software platform. It's a continuation of a drumbeat that started after last year's rash of zero-days, and one that has now gained an officious band leader in the form of the Department of Homeland Security's Computer Emergency Readiness Team (CERT), which this week suggested users disable Java in Web browsers.

But disabling Java is not a simple prospect for enterprises that may depend on it heavily to run business-critical applications.

"For a lot of home users, it's true you can disable Java or uninstall Java, and it may not really affect your experience online," says Liam O Murchu, research for Symantec Security Response. "But for businesses, Java is used a lot for more heavy-duty applications. So from a business point of view, it is a little more difficult to say, 'OK, let's disable Java,' because it may be needed for your day-to-day business."

So the question is, without breaking these applications, how can enterprises mitigate the risk of Java zero-days becoming just the vector crooks are looking for to start attacks that compromise their databases? And, further, should enterprises be questioning their dependence on Java in the first place?

The Latest Threat
The most current Java troubles came to light late last week as the security research community alerted followers of the use of a Java zero-day within Blackhole and other exploit kits.

"What's really capturing people's attention with the current one is it was used in Web exploit packs from day one, which is unusual," O Murchu says. "What we normally see with zero-day vulnerabilities and exploits is they're used in targeted attacks because they're very valuable. But in this case, the exploit was used the first time in an exploit pack."

That means compared to other Java zero-days in recent memory, this one could pack a more meaningful wallop as compromises are bound to be more widespread, he says.

[Java was only one of several applications prone to vulnerabilities in 2012. See The Vulnerability 'Usual Suspects' Of 2012.]

For its part, Oracle responded more quickly to this particular zero-day event than it did to problems found in August, releasing a patch within days for the vulnerability in Java 7 Update 10 that allows for a remote, unauthenticated execution on affected systems. With the patch, Oracle also switched the Java security settings to "high" by default on its plug-in software.

"The high security setting requires users to expressly authorize the execution of applets which are either unsigned or are self-signed," wrote Eric Maurice, software security assurance director for Oracle, in an Oracle blog that's the only public comment the company made about the issue. "As a result, unsuspecting users visiting malicious web sites will be notified before an applet is run and will gain the ability to deny the execution of the potentially malicious applet. Note also that Java SE 7 Update 10 introduced the ability for users to easily disable Java in their browsers through the Java Control Panel."

But the problem, experts say, is that the patch provided by Oracle didn't go far enough to close the root issues that left the hole open. Those issues are significant enough that it will take a lot of under-the-hood renovations to remedy, says Paul Henry, security and forensic analyst for Lumension.

"The underlying cause of the vulnerability is not being fixed with this patch, and I'd guess it's a year or more before we see that problem truly solved, which will require some fundamental changes to Java," Henry says. "In the meantime, while we wait for that or a fundamental change to Java, you should apply this patch to buy some time and prevent this particular expression of the vulnerability from activating on your machine"

That innate vulnerability of the program even with a patch, its widespread compromise through a highly propagated malware kit, and the added factor that this is one of many Java zero-days to surface over the last year have all contributed to CERT's warning to disable Java in the browser altogether.

"This and previous Java vulnerabilities have been widely targeted by attackers, and new Java vulnerabilities are likely to be discovered," CERT said in its notice about the recent vulnerability. "To defend against this and future Java vulnerabilities, consider disabling Java in web browsers until adequate updates are available. As with any software, unnecessary features should be disabled or removed as appropriate for your environment.

The Enterprise Conundrum
The immediate reaction from many IT managers at suggestions of disabling Java is, "Not if I want to keep my job." Many enterprises depend heavily on Java for their internal business applications and other Web applications, and managers worry that flipping the switch on client Java installations would break their applications.

"But that's not as universally true as you'd think," says Wolfgang Kandek, CTO of Qualys.

As he and other security experts in favor of reducing enterprise Java risk exposure have been ready to explain recently, in most cases disabling client Java capabilities on users' machines won't necessarily wreak havoc on business applications.

"An important distinction needs to be made between in-the-browser Java and the far more common Java runtime environment," says Jo DeMesy, senior analyst for Stach & Liu. "This vulnerability does not affect Web applications that utilize the Java server-side, which is by far the most common use of the Java programming language. The vulnerability lies within the Java runtime exposed to Web clients, which load a malicious Java applet. This type of implementation is much less common [in enterprise applications]."

Even if the enterprise has to run client-side Java applets to keep certain business-critical applications running, there are ways to mitigate the risk of browser-based Java vulnerabilities. A lot of it comes down to the fundamentals of setting policies, procedures, and guidelines.

"It's really boring, but it really does work," says Steve Santorelli, director of global outreach for Team Cymru. "These will help determine for the users what sites you can go to and what Java-related technology you can install on a machine. But these are very time-intensive and involve whitelisting, blacklisting, dealing with alerts, and all of the technical support for it."

Fortunately, many browser vendors have eased the burden with features to make it easier to support and enforce policies.

"For example, the Google Chrome and Firefox browsers have a "click-to-play" feature for browser plug-ins, which simply requires a user to explicitly click on the applet before the browser exposes any functionality," DeMesy says. "This feature can be used to stop sites from hiding these malicious applets within seemly innocent pages."

But before organizations can even think about these workarounds, they need to get the lay of the land to understand their dependence on Java, the risk posed by installations, and what it will mean to business processes if IT begins pushing down restrictive policies.

"Before they can do that, they have to assess. Is this going to break any of our applications? Are people not going to be able to make payroll or get on our training applications if these policies are pushed down?" says O Murchu.

According to Kandek, it makes sense for organizations to take an inventory of all the server-side and client-side instances of Java within their organization and rank them by business criticality. So the situation is not an impossible one, he says, but it will still cost organizations to adjust their course.

"This is going to cost some money and resources to deal with," he says. "But it's the only way to develop a strategy on how to tackle this. An inventory will find instances of Java being used client-side and, even worse, applications that depend on old versions of Java."

Curtains For Java? Not Likely...
The negative buzz around Java has naturally stoked speculation about the future of the platform within the enterprise and beyond.

"Long term, enterprises should seek to move toward implementing HTML5 and other native browser technologies to replace these antiquated plug-ins," DeMesy says.

Henry agrees: "So many Internet applications require Java to function. The developers of these applications need to be looking at alternatives."

However, given that most of the vulnerabilities cropping up today are within the browser environment and how tightly woven Java is within server-side application implementations, don't count on Java going the way of the dodo any time soon.

"And you also have to bear in mind that Oracle isn't going to be standing still," Santorelli says. "In the same way Microsoft had a sea change in the way their developers handled security; you could argue Oracle's going through a similar process."

He believes it is very unlikely that Java will die off as a result of security problems.

"If you look back at previous instances of a particular type of technology withering away, the reality has been that that's been driven from business factors," Santorelli says. "If Java's user base shrinks to an unsustainable level, it isn't going to be because of a direct consequence of perceived security flaws."

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.