Data Centers

Java insecurity: Options are few for many enterprises [Update]

Scott Lowe explains the challenges of trying to remove Java on an organizational level, a route many IT pros --tired of dealing with continual exploits -- would love to take.
[Author's note: This article has been revised to include additional research to correct factual flaws that appeared in the original version. Please accept my apologies for the initial misinformation. - Scott]

By now, you've probably heard that Java has once again been the target of another 0-day exploit thanks to underlying weakness in the Java code. This is not the first time that Java has been in this position. Just last summer, a 0-day exploit was making the rounds thanks to a different coding issue.  Some experts predict that it could take Oracle up to two years to fix all of the vulnerabilities in the Java code, so it's more than likely that we'll be facing similar news in the not-too-distant future.

With last week's news about the exploit hitting all of the networks, security experts and even the Department of Homeland Security issued dire warnings with the recommendation that users take immediate steps to fully disable Java in their web browsers. These discussions surrounding the decision about whether or not to disable Java continue to make the rounds even though Oracle issued an emergency patch a couple of weeks ago, although additional vulnerabilities have been discovered since its release.

It should be noted that these newest vulnerabilities directly affect Java 7 SE only. While one of the vulnerabilities is present in Java SE 6, it is not considered high risk in Java SE 6, as exploiting it first requires exploiting a Java 7 SE-only flaw (not present in Java SE 6).

The specific flaw this January was one that could allow an attacker to exploit a security weakness and run arbitrary code on the host system.  Any web browser using the Java 7 plugin was affected - and continues to be affected by newly discovered flaws. A security company's test revealed that the exploit worked on a fully-patched 32-bit Windows 7 system under Firefox, Internet Explorer, Opera, Chrome, and Safari; in other words, every browser was at risk.

To disable or not...

While home users have been warned to disable Java in their browsers as soon as possible, enterprises don't always have that luxury. A number of enterprise applications rely on the ability for browsers to invoke Java applets. However, even some enterprises are taking steps to protect themselves by disabling Java in their web browsers and some browser vendors have taken things a step further. Even Oracle has gotten into the game by making it easier

With the latest updates from Oracle, Oracle has made it easier to disable Java in all browsers on the system. Here are instructions. In addition, the latest patches from Oracle also change Java security settings to require user authorization before executing applets that could attempt to exploit as-yet-undiscovered vulnerabilities.

Here are the four routes that I can see organizations taking with regard to Java:

  • Maintain the status quo. Keep Java and browser plug ins patched and keep it enabled. This approach is required for organizations that rely on Java applets in web browsers. This is the riskiest option of the bunch.
  • Run in a sandbox. For organizations that really want to disable browser-based Java but are unable to do so, there could be a confined virtual machine sandbox that's used for this purpose. While an attractive option on the surface, this option comes with massive administrative overhead.
  • Selectively disable Java plugins. Personally, I see this option as being the most palatable. Keep Java browser-enabled just for systems that require Java applets tools and disable it for everyone else. In doing so, you minimize the exploit risk while ensuring that your tools remain available. I know of at least one college CIO considering this route right now.
  • Kill it... kill it now. This is the knee-jerk, operations-affecting decision. For some, security may be so tight that Java just has to go altogether. In doing so, it's possible that an app or two might get taken down with it. I don't see this route being taken by very many people. While the recent vulnerabilities have been shown to affect only browser-based Java plug ins, there are some out there disabling Java across the board.

On the browser front, some browser vendors have taken steps to protect their users from potential Java vulnerabilities. Right now, Apple and Firefox have taken the most substantial steps. Apple has updated its security mechanisms to disallow old and unpatched versions of Java from running in the browser. Firefox has added even recent versions of Java to its "Click to Play" list, which is a mechanism intended to help users prevent drive-by downloads that could result in malware infestation or exploitation of vulnerabilities.

What about you? What steps, if any, are you taking personally or in your company?

About

Since 1994, Scott Lowe has been providing technology solutions to a variety of organizations. After spending 10 years in multiple CIO roles, Scott is now an independent consultant, blogger, author, owner of The 1610 Group, and a Senior IT Executive w...

23 comments
bretthexum
bretthexum

As someone who deals with application packaging, QA, and deployments -- security isn't the only issue here. Enterprise anti-virus, firewalls, proxy servers, etc seem to mitigate a lot of the risk. Personally my biggest issue with Java 1.7 is the forcing of auto-updates and the nag screens that come with it. This is a huge problem and results in massive numbers of helpdesk calls if not dealt with. Before Java 1.7, engineers had time to test, package, and pilot Java releases. Now, each time a new update is released the end users themselves get prompted about insecure versions of Java! Not good. I've written a messy workaround for this HUGE issue (in my opinion). http://www.labareweb.com/java-1-7-auto-update-deployment-with-sccmmdt/

Lawrence Garvin
Lawrence Garvin

While it's true that the current (January) exploit patched by JRE7u11 was only accessible through web-based code, I think it's naive to think that the same level of careless programming that went into the web-based portions of the Java Runtime doesn't also plague the non-browser portions of the code. Possibly the only reason they don't is that much of that code was written prior to JRE7, and thus not subject to what appears to be some very dysfunctional coding practices inside Oracle. Nonetheless, as Scott points out in his article, we all recognize that disabling (or uninstalling) Java completely is not a viable option, and thus the focus continues to be on disabling the Java functionality in the browsers -- which is the primary vector of attack. Then again, related to general patch management and appDeploy practices.. if you don't *need* Java... in any form... it's still Best Practice to uninstall the unneeded product.

Scott Lowe
Scott Lowe

All, Thank you for the feedback indicating that there were factual errors in the article. I have read your feedback, done additional research and updated the article in question. Please accept my apologies for the initial misinformation. Scott Lowe Author

mla_ca520
mla_ca520

The criticisms are correct on this. The software being exploited is java in the browser. In fact, anarticle on Networkworld references the CMU SEI CERT recommendation: "Unless it is absolutely necessary to run Java in web browsers, disable it, even after updating to 7u11." So this zero-day security problem seems to be largely focused on java in the browser, not client side applications or server side applications.

viProCon
viProCon

Java is the one product that irks me the most, as an IT admin. Why does this thing not have a global admin console you can run from a server to manage all systems? Or does it? Java is "there", but I would be fine seeing it disappear. I do remember the write once, run anywhere selling point. Problem is/was the code was never efficient. Somebody needs to sit down and think about a Java 2.0.

osas1
osas1

It's just a bug they detected. Don't panic it will be resolved soon!

maszsam
maszsam

Aside from the recent issues, Java has a lot of other negatives, not the least being able to get up to speed using it. Any time there is this much pressure on a given industry need, other solutions come along spurred on by the hugh monetary gains possible for the production of a better alternative. In the 1800's trains ran on different size tracks. Was the practicle solution to build a locomotive that fit everthing? At some point, who knows when, not me, an acknowledged best hardware solution will prove itself and the nonsense will end.

Deadly Ernest
Deadly Ernest

summer for half the world was back in January 2012 and I suspect you mean sometime around June July 2012.

Deadly Ernest
Deadly Ernest

the moment. That's one hell of a huge potential botnet if someone takes advantage of the vulnerability to hit a lot of phones via their web access. With the regular surfacing of Java vulnerabilities, I suspect the time really is NOW for enterprise and people to move away from it for all time.

flotsam70
flotsam70

No, it isn't, Chicken Little. It's one cloud that's leaking and needs fixed. Mole hill -> Mountain. Seriously.

CharlieSpencer
CharlieSpencer

I thought it was either installed or not. Now that I know, if you're going to disable it then why not go ahead and uninstall it?

Knighthawk5193@Yahoo.com
Knighthawk5193@Yahoo.com

While I haven't the first CLUE about whether or not my desktop at work is safe or not, becaue I'm in charge of a whole LOT of desktops, and because the information on the servers those desktops connect to is EXTREMELY IMPORTANT (think Level G15 Government Clearance, and you being to get the picture!) I would rather be safe than sorry, there is no reason for Java to be on the network, the most processor intensive applications we have are office / spreadsheet / presentation software, and hwile we don't block all internet access, we sure do monitor it vigorously, there's hardly a complaint from anyone who uses the internet on campus who feels they need to have Java running....so there ARE a few places that truly DO have a Java free network. I doubt that there are many, and I'm almost certain there are a few proplr who have attempted to acess Java-rich sites that might cause problems, but most of our network access (externally) is role monitored, if you're not in a specific role, you don't get access.....simple.....clean.......precise.........brutal?....yes. Might there be another way to do it?....most definitely, but since it works for us.....we'll keep it this way until the powers-that-b decide to do things diferently.

ergdemirel
ergdemirel

I agree with arash1988 - it's clearly stated in security alert that no desktop, server or every other major use of java has this kind of problems. I assume that there is a big misunderstanding of Java on Browser vs Java everywhere else in this article!

jag022054
jag022054

Anyone know how much of these problems are shared by OpenJDK?

arash1988
arash1988

Java on servers, embedded java, desktop java and every major use of Java in the industry you can think of is not vulnerable at all. This vulnerability only affects Java plugins in the browsers, and this makes your headlines very misleading. You probably don't have any idea what a "java-free operating system" really means. Thousands of big enterprises are relying on Java-based desktop applications which are not affected at all. Even more have a major part of their software infrastructure based on server-side java technologies which are not vulnerable as well. You only need to disable the Java browser plugin to be safe against recent attacks. You don't need to "kill it", "remove it" or "disable it in the OS".

berta
berta

According to Oracle's emergency patch JDK and JRE 6, 5.0 and 1.4.2, and Java SE Embedded JRE releases are not affected. As I remember 5.0 will retire soon, only JRE 6 left. If it is true, just disable the 7.0.

JCitizen
JCitizen

to those who realize that the disabling of java, while still resident in the on-board applications , is a frustrating attempt at a fix. I use Comodo Dragon(Chrome) with Script Safe, and I think I like it better than No Script, because it also tends to be just another "always allow" option. Script Safe is a little different in the way it is controlled, and I find I can take steps to gain functionality on web sites without allowing as much as seems necessary with No Script. Bottom line is at least these two plugins, and probably others, are definitely better than nothing. I am convinced though, that my blended defenses, will make the attacking code's success very much less likely. My tests of the various HIPS based utilities I use have so far caught every malicious file I've downloaded on my honey pot. If one solution doesn't stop it, something else always does. I base this success on well designed software that doesn't rely on signatures, and are kernel based to resist manipulation by the malware. It is even getting hard to find sources for zero day threats to test these solutions. Many in this field are employing junk email accounts to farm up spam, which seem to be the best source for active threats right now. The criminals will never sleep on this, so the mine fields are ever changing, and anyone involved in IT SEC is already well aware of this. The evolution of security solutions has been mind boggling in just the last two years - but it has become necessary as well. Kudos to Microsoft for improving on the NT5 and 6 model for hardening their operating systems, as this has given us at least a leg up on the problem.

JCitizen
JCitizen

and thanks! As far as my personal home office computer though, I wished I could get it to do exactly that! I've never been able to, or witnessed the java updater working in my Vista x64 Ultimate PC. Java hides the update tab in the java console, in my version of windows, and if I remember correctly, I used a registry hack to get it to show when opening it in command line. But after several updates it disappeared again, never to return. I end up using Avast's software updater to get java updates from now on.

radleym
radleym

...if he can't understand the difference between a browser add-on and a workstation programming language or a runtime environment.

Duke E Love
Duke E Love

and not the JVM that runs Enterprise apps that is at risk

radleym
radleym

You run either OSX or linux in your organization, as much of what you say about Java goes double for Windows.

admin
admin

Glad to see some people actually read the security alerts!

Editor's Picks