Application Security // Database Security
1/16/2013
05:35 AM
Connect Directly
RSS
E-Mail
50%
50%
Repost This

The Death Of Java In The Enterprise?

The continued waves of Java zero-days have security experts recommending that enterprises reevaluate how they use Java

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.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Andrew Binstock
50%
50%
Andrew Binstock,
User Rank: Apprentice
1/25/2013 | 10:56:35 PM
re: The Death Of Java In The Enterprise?
Quite true.-áJava is-ámostly for sites that want to run applets in your browser. There are not many of those.
macker490
50%
50%
macker490,
User Rank: Ninja
1/20/2013 | 4:35:21 PM
re: The Death Of Java In The Enterprise?
getting hacked can be rather costly . consequently it behoves us to evaluate the software we have in service with respect to security problems .

there are no big secrets : the usual suspects are responsible over and over and over again . some of these products are probably beyond repair as they were not designed with security in mind at the start .

which makes it evident we need to switch to software products that take security seriously .

Andrew Binstock
50%
50%
Andrew Binstock,
User Rank: Apprentice
1/18/2013 | 10:47:53 PM
re: The Death Of Java In The Enterprise?
The web-based Java apps are not the problem. They're just hosted on Java servers, but tend not to be Java applets that run in the browser. It's only a Java applet that runs in the browser that's a problem. That's the only way currently to get the malicious payload.
Lawrence Harris
50%
50%
Lawrence Harris,
User Rank: Apprentice
1/16/2013 | 5:12:50 PM
re: The Death Of Java In The Enterprise?
-áMost browsers are running javascript not java.-á I very rarely find anything that requires java in the browser.-á Java as an application tools is great as a browser plugin is unnecessary in 99% of the cases
chipk77
50%
50%
chipk77,
User Rank: Apprentice
1/16/2013 | 3:10:41 PM
re: The Death Of Java In The Enterprise?
Wow, that's a really great idea. Industries that have poured millions into web-based Java apps should just stop using them. Why didn't anybody else think of that?
dkerber028
50%
50%
dkerber028,
User Rank: Apprentice
1/16/2013 | 3:07:42 PM
re: The Death Of Java In The Enterprise?
Easy:-á don't use java in a browser.-á All the vulnerabilities I've seen so far have been when from that use case (unless I missed some).-á Using java for desktop apps and server-side still has its place, and will for a long time.
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-1421
Published: 2014-04-22
Cross-site scripting (XSS) vulnerability in Craig Knudsen WebCalendar before 1.2.5, 1.2.6, and other versions before 1.2.7 allows remote attackers to inject arbitrary web script or HTML via the Category Name field to category.php.

CVE-2013-2105
Published: 2014-04-22
The Show In Browser (show_in_browser) gem 0.0.3 for Ruby allows local users to inject arbitrary web script or HTML via a symlink attack on /tmp/browser.html.

CVE-2013-2187
Published: 2014-04-22
Cross-site scripting (XSS) vulnerability in Apache Archiva 1.2 through 1.2.2 and 1.3 before 1.3.8 allows remote attackers to inject arbitrary web script or HTML via unspecified parameters, related to the home page.

CVE-2013-4116
Published: 2014-04-22
lib/npm.js in Node Packaged Modules (npm) before 1.3.3 allows local users to overwrite arbitrary files via a symlink attack on temporary files with predictable names that are created when unpacking archives.

CVE-2013-4472
Published: 2014-04-22
The openTempFile function in goo/gfile.cc in Xpdf and Poppler 0.24.3 and earlier, when running on a system other than Unix, allows local users to overwrite arbitrary files via a symlink attack on temporary files with predictable names.

Best of the Web