Discussion on:

Java insecurity: Options are few for many enterprises

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.

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.

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".

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

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!

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.

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?

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

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.

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

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.

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

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.

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.

I can not access the article... Get "Were sorry, but the page you requested could not be found."
Searching Tech Republic for article gives me the same link:
http://www.techrepublic.com/blog/networking/java-insecurity-options-are-few-for-many-enterprises/6302

Anyone have a working link to the article?

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

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.

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/