Java - the enterprise technology we (still) love to hate

It wasn't that long ago, in fact it was August, when I wrote this piece called "Java in the crosshairs of Enterprise Security" about the very difficult frustration of Java, and its impact (both positive and negative) on the lives of enterprises. Check out what I previously wrote, because it all still applies today with this latest big bug. Luckily, this latest bug is only exploitable in browsers ...whew! That narrows it down.


While this particular vulnerability CVE-2013-0422 is only exploitable with the browser plug-in, Java on the endpoint isn't just in your browser, by the way, it's nearly everywhere. Much to the chagrin of those in the security community who loathe it, it's in your disc players, some of your phones, cars and various other Java-run devices. The challenge for Java is in its ubiquitous nature - it's a true "write once, run everywhere" type of platform which also leads to why it's attacked and researched so heavily. Attackers know that if they find a flaw in the Java platform, they'll likely be able to write cross-device exploits and let Java handle the platform-specific internals. This doesn't really help any of us in security to sleep at night.


Another interesting aspect of Java is that the recommendations given for disabling are geared not at the enterprise, but at the end-user. I can only imagine how frustrating this can be for enterprises who manage workstations by group policy or some software delivery mechanisms. US CERT has a reasonable write-up on removing the fangs from the Java monster, and while it's not quite as simple as pushing one universal uninstall, registry key, or GPO option (mainly due to the various version and their install differences) it's do-able.


Here's the catch: some enterprises absolutely rely on Java on the desktop to get business done. In fact, if you work as an Information Security professional the odds are quite good that you're opening up a Java-based applet to manage your network security device... So the advice to simply remove or permanently disable Java sounds like a great idea until you consider your reality.


Is Java going away in the enterprise any time soon? I doubt it... the industry has been calling for its demise for a long time but it's still around. In fact, until something (possibly HTML5) comes along that provides the functionality that Java provides along with the ubiquitous nature of the platform, it's going to be very hard to replace it, and so we're left in the lurch.


A few thoughts...


  • "Power Users" (the security-conscious and willing) will likely disable Java altogether if it isn't required in day-to-day activities
  • Some people will opt to have a browser (I use Internet Explorer) which is the only one that still runs Java and is never used except for corporate apps (carefully set as not the default browser, etc)
  • Java enterprise users will need network-level support to catch the attacks as soon as there are workable active signatures for the attacks... Which is all the more reason to proxy all of your Internet traffic (where possible)
  • Some enterprises will simply disable Java enterprise-wide, or maybe even uninstall it via their software management products and tools... until some 3rd party app comes along that requires Java to view your yearly W2 or access your payroll profile
  • Corporate support will continue to be a nightmare
  • Home users will probably never see this and never disable Java. (It comes pre-installed on many Windows-based operating systems and be exploited, which is why exploit research like this is done.) Their anti-virus likely won't protect them from the attack either because they haven't updated the product in years, it's broken or they simply have a poor product in place


What Oracle needs is to build in a more robust method for enterprise management of Java, or at least a simplified interface for scripted tools to detect, update, control and/or remove the software. I think Java can be a good thing, if Oracle can invest the time in securing the platform.  But there is still an alarmingly large pile of work to be done to make it "enterprise ready."


We, as security professionals, can't just say things like "disable/remove Java" haphazardly because it's a necessary component of many enterprises. We need a real alternative to mitigate the risks that Java may pose... even if the answer is temporarily disabling the plug-in while Oracle gets its act together.



Andrew Storms, Director of Security Operations at nCircle is just as frustrated...


"Java’s not going to go away on corporate desktops anytime soon, so the best we can hope for is a way to manage it more effectively.


Corporate security needs mitigation advance to reduce the risks associated with any serious vulnerability while vendors deliver a patch, this is true for all corporate software. Since the recent Java attack vectors have  been confined to browsers  the obvious mitigation tactic is to disable Java in the browser. Oracle probably thought they ‘solved’ the mitigation problem by delivering a control panel that allows the user to enable or disable Java in browser.


I have news for Oracle -- without a way to manage this setting centrally this ‘mitigation’ is almost useless. Asking tens of thousands, or even several hundred corporate users, to open a control panel and unclick a check box is ridiculous. I’m not sure what kind of thought process created this option over in Redwood Shores, but I doubt Oracle’s own security team uses this method to control corporate desktop software configurations.


This response has left corporate IT rummaging through their Java installations hoping to find some secret sauce in the registry that will make it possible for them to control Java’s behavior on the desktop. So far, we’ve all come up empty handed."



What do you think? Are you struggling to tame the Java beast in your medium or large enterprise?

Any tips, suggestions or hints you'd like to share?



Related reading:

Richard Steven Hack(anon) | ‎01-17-2013 09:57 PM

"We, as security professionals, can't just say things like "disable/remove Java" haphazardly because it's a necessary component of many enterprises."


Which begs the question:  Why is it a "necessary component?" Which in turn begs the question: Why is anything a "necessary component?" Which in turn begs the question: Since everything by definition is a "necessary component" - including insecure computers themselves - why aren't we asking the REAL question?


Which of course is that everything is insecure and how do we deal with that?


"Asking tens of thousands, or even several hundred corporate users, to open a control panel and unclick a check box is ridiculous."


Why? Corporations ask their employees to do much worse every day... Or aren't employees supposed to be "part of the security team?"


And why hasn't it been taken care of already?  Java has been known to be a major attack surface for what, the last couple of YEARS? How long are corporations going to wait to deal with the issue once and for all - by eliminating Java as a "necessary component"?


Fish or cut bait. You either want "security" or you don't. You either take the steps necessary to at least approach some level of "security" or you don't. No, the reality is that corporations want to do everything they're doing now - including using an insecure platform like Java - and still demand "security".


Sorry. Can't be done.  CEOs don't make the tides change any more than emperors do.


The reality is my meme: "You can haz better security, you can haz worse security. But you cannot haz 'security'. There is no security, Deal."

AlvaroM(anon) | ‎01-21-2013 06:13 AM

Im surprised that the Oracle Security alert referenced in this post states that these vulnerabilities only affect applets. As far as I know, these vulnerabilities can be used to load any restricted class and to disable the java.System.SecurityManager.

Security managers are not only used to sandbox the applet running on the browser JVM but for many other types of applications as well. Just to put an example, any Java server or desktop application with a plugin architecture, normally run these plugins from a restricted classloader with a security manager in place controlling what the plugin can or cannot do. These vulnerabilities can be easily used to avoid those restrictions. Yeah, you need to trick the user to install a malicious plugin in those applications ... is that difficult to do for a determined attacker? are those Java applications servers or desktop JRE's always up to date?

Blair Nastasi(anon) | ‎01-21-2013 11:03 AM

There’s an easy way to disable Java immediately using Group Policy or your own management tool. We have a blog and video to show you exactly how to do it:

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
About the Author

Follow Us
Community Announcements
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation