Disable your Java - NOW

forestgiant

'was on the way back from lunch when NPR made a story about a vulnerability on Java 7 update 10 and earlier (that makes it applicable to every Java release to date).

in short: Disable or uninstall your Java, like NOW!

More info at the US CERT site for Vulnerability Note VU#625617.

ptilsen

I have briefly looked into it, and my initial conclusion was there are still secure Java 6 versions. The new vulnerabilities are only for Java 7.

I haven't made time to properly research, so if someone could link to conclusive evidence either way that would be awesome. I do know all of 7 is insecure.

lsud00d

This happens like once a month

atorven

What lsud00d said. What do people in secure environments do when these vulnerabilities are discovered, disable Java (what ever application) in the whole organization? What if your applications stop working?

ptilsen

It's a pretty serious issue, for me. We have multiple applications across BUs and departments that require different versions of Java. My gut reaction is to actually blacklist Java, but that is not feasible. Moving users to VMs or terminal servers for Java apps to get Java off their workstations isn't practicable in any short term. We're not a high-sec environment, but a vulnerability this widespread is truly difficult to mitigate but pretty necessary for any environment.

crrussell3

If you can't uninstall/disable java, at least block it in the Internet Zone and only allow it in the Trusted Sites or Intranet Zone. I put out a gpo a couple months ago. This isn't 100% but better than nothing.

Roguetadhg

Java has a new vulnerability? That's like saying that space is cold.

forestgiant

These advisories come early and often, but what's different this time is the US CERT explicit involvement.

I suspect the govt knows someone (or some nations) is about to exploit it on a wide scale. Fortunately in my environment Java is helpful but not critical so we just uninstall it until we hear confirmation from Oracle or US CERT that a newer version fixes the vulnerability.

ptilsen

In doing some more research, it looks like the exploits from a few months ago affected more or less all versions of Java. This new exploit appears to be limited to Java 7.

For the enterprise, ensuring only Java 6 is in use and limiting its use to business necessities seems to be the best approach. Software Restriction Policies and Internet Explorer policies seem to be the best approach for most environments.

CodeBlox

Can't just uninstall JAVA otherwise a few integral apps here stop working...

Roguetadhg

Likewise, Code. There's not enough money to fund dumping Java as there's a lot of programs we use internally and externally that use Java. It is what it is.

ptilsen

After some more research, it looks like every version of 6 is vulnerable in other ways. I already viewed Java (and Flash, Reader, et al) as an inherent risk, but my conclusion is that there is currently no functional version of Java for which there isn't functional, published exploit code on the Internet. For organizations that rely on JRE, the only practical mitigation techniques I'm finding are limiting user rights and limiting Java use to the Trusted Sites zone. The impractical mitigation technique would be to use a web browser in a VM for any Java needs.

lsud00d

Gotta sandbox the wild ones somehow!

MentholMoose

One option is to package Java applications and Java itself into application virtualization sandboxes, e.g. using App-V, XenApp, or Thinapp, and not have Java installed locally. I think most Java exploits are browser-based, so not having a local Java or browser plug-in should greatly reduce the chance of infection. If the sandboxed Java somehow gets exploited, the malware will probably crash or at least not function properly due to the unexpected, restricted environment provided by the application virtualization software, and cleanup would probably only require clearing the sandbox cache.

If you have a browser-based application that requires Java, you can build a package for it and instruct users to not use that browser to browse elsewhere (and hope the site with the application doesn't get compromised). You can try things like hiding the address bar in the packaged browser environment to discourage browsing elsewhere. Such a package may only need Java itself and a shortcut to open the locally installed browser in the sandbox environment, or you can package complete browsers in some cases.

ptilsen

We have numerous Java-based web apps, not to mention an unknown number of necessary websites, and some even use single sign-on. Is it possible to use an App-V browser with the Java plugin enabled? Other methods do not seem practical for my environment. I could see deploying that and preventing Java from being installed.

Edit: Apparently reading up on App-V is long overdue, in my case. App-V specifically is designed to allow virtualized IE (or other applications, even) with plugins.

MentholMoose

Yes, App-V and other application virtualization tools are very well suited to this. You can package multiple applications and dependencies (e.g. Java) into one package, or build several separate packages that depend on each other, or a combination thereof. You can launch local applications (e.g. IE) in the sandbox with necessary plug-ins. It is great for situations where different applications need different Java versions since each package can have it's own Java and not conflict with anything else. App-V has a local install mode where you build MSIs and deploy them however you want, as well as a streaming mode where applications are published and streamed to desktops as needed.

Of course it probably won't be easy, and it may take a while to get most of the applications in a typical environment packaged. Doing it solely for security reasons probably wouldn't be worthwhile, but there are other benefits. At my previous job we used App-V and the security benefits probably weren't a factor at all.

ptilsen

The security risk is pretty huge, for us. We have lots of users with admin rights, which means a user context exploit doesn't leave too much in the way of compromising the whole domain. To me, it seems like it's worth doing solely for the security risks, though I don't have a good handle on how much work it would be.

MentholMoose

The difficulty and time required will vary. The number, complexity, and quality of applications, how many people are doing the packaging and their experience level, and other things will come into play.

At my last job we supported about 150 applications. Not all applications were packaged (I believe we had 70-80% in App-V). Some were too small to bother (e.g. single EXE stuff just went on a file share), some were purposefully installed locally (e.g. MS Office), and some simply wouldn't package no matter what we tried. They were mostly done by another sysadmin by the time I was hired, so I was mainly packaging updated or new programs.

One big problem with App-V (and application virtualization in general) is that few vendors support it. If you call and ask a vendor about using their software in App-V, 99% will have never heard of it or say it's unsupported. There are few exceptions - I remember one vendor actually built a new EXE of their application that worked in App-V - but not many. Application virtualization is definitely useful, but is best used in conjunction with other solutions such as VDI (View, XenDesktop) and presentation virtualization (Terminal Services, XenApp).

If you go with App-V and decide to attend formal training to get up to speed, make sure it includes a major troubleshooting component covering problems encountered with packages. Also, I would confirm the trainer has real-world experience. If they are mainly delivering standard content from a book, using some basic sample applications to demonstrate packaging, I would be hesitant to attend. It is best to get training from someone who actually has packaged stuff and can give you tips that only come with experience. I never attended formal training, but the informal training provided by my coworker who had packaged 100+ applications was probably more valuable than any class.

For self-study, I would recommended Mastering Microsoft Virtualization as that is what I used to get certified with App-V. Also there are blogs and forums out there. But basically you have to package a lot of stuff to really learn App-V. Lastly, get a fast machine with an SSD (or a VM with a disk on a fast SAN) to do packaging. Waiting an hour for a package to build only to find a problem during testing that requires repackaging is no fun.

SteveLord

When it's not Java, it's some Adobe product.

instant000

Yes, it's nothing new. I was kinda surprised that it was getting so much attention, when I assumed that a few products: Adobe Flash/Reader, and Java had new vulnerabilities every month.

I guess the issue with this one is that there's no updated version to run that eliminates this vulnerability. Some browser/systems makers have taken it upon themselves to disable Java for you, which makes this issue seem pretty bad.

CenturionMario

This is somewhat of a late post, but I have been attempting to learn Java programming, and I use the command prompt as a java compiler. Is this a security risk? I disabled java on my web browser about a week ago, but does this also apply for offline usage? Should I uninstall Java completely?

kremit

SteveLord wrote: »

When it's not Java, it's some Adobe product.

I know right? It's funny how some companies, not naming any, rely only java for nearly 99% of their business and yet it has problems like this all the time. But you know what's more scary? Social engineered attacks. Happens all the damn time.

DevilWAH

This reminds me of not long ago when every day some one shouted to remove windows because of security exploits.

well managed security in a company can mitigate these issues, and if you want to get really scared just look at the exploit lists for any OS or well used software package..

Makes you want to turn of the Computer and go back to pen and paper!!

RobertKaucher

Just to be clear, this is only an issue with Java running in browser. If you are executing code on the file system, JVM or no, your system can be owned by anything. If you have enterprise Java apps that are not browser based, it's fine. Just restrict Java in the browser.

CenturionMario

If you are executing code on the file system, JVM or no, your system can be owned by anything.

What exactly do you mean when you say this? Are you saying that myself or someone else (remotely) can destroy the system when I'm trying to compile java programs? Does that mean myself (and anyone else that tries to program in Java) is taking a risk?

RobertKaucher

If you are executing code on your file system, such as an EXE file, that code should be trusted. You should trust the source from which you obtained it. If you are downloading random programs off the Internet and executing them, you are going to get in trouble if they are Java based or written in C. That doesn't matter.

The problem is not so much in Java itself, it is that Java is allowed to execute in the browser. If you disable that aspect of Java it is no more or less a security issue than anything else on your PC. But if Java can run in your browser, you are basically allowing "executables" from any place on the Internet to be run automatically. Again, this is why we get in trouble with Java.

CenturionMario

I understand, now. Thank you for the information. I don't have to worry too much, then.

forestgiant

This thread's taken a technical perspective but I've just seen first hand the business driver behind Java's vulnerabilities. My employer's got a e-commerce platform on Java 6.x and initially the behind doors discussions and decisions were to do nothing as the threat factors were on the clients' side. Guess what --- most of our customers were non-profits and universities and some uninstalled Java from end-point stations. By my rough calculations, that's over 20K potential customers who could no longer use our e-commerce platform. Ouch! The phone's been ringing off the hook at customer service desks with people who blame us for incompatibility issues (when they no longer have Java at all), and we're back to paper purchase orders like it was the '90s.

RobertKaucher

forestgiant, that's the environment right now for sure. And I am in no way attempting to detract from the giant pain in the @$$ this surely is for you. But your story makes me think maybe MS really did the right thing with Silverlight by more-or-less killing it. In 2010/2011 I invested a ton of time in learning Silverlight (which to be honest was amazingly advanced compared to Flash or Java) and my company was set down a chunk of change for Silverlight based controls. Then everyone realized that heavy in-browser, frameworks were too vulnerable and too much of a relic of the desktop era to live. SL5 will likely be the last version we see. Flash mobile is dead, I suspect Flash will eventually be going the same direction.

But honestly, it was time. The world has changed.