In a high-level study of Java and its vulnerabilities, endpoint security company Bit9 found that nearly half of...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
all endpoints have more than two versions of Java installed. Java is so pervasive and organizations are extremely ineffective at closing down their threat surface area by removing old versions -- making them easy endpoint targets for attackers.
People don't understand that installing Java doesn't remove older versions. Make sure you upgrade, not install again. That's one of the reasons there are so many versions of Java on endpoints.
lead security researcher, Bit9
Java, known as the "write once, run anywhere" platform, is installed on nearly every computing device. Many websites and web applications require Java to operate properly -- try turning it off in your browser to see just how many.
In 2012, thanks to this popular platform's many vulnerabilities, it became the technology most frequently exploited by attackers. Bit9's just-released "Java Vulnerability Report: Write Once, Pwn Anywhere" provides insight into just how bad the Java problem is.
Java is bad in a special way
Java is frequently slammed, with people claiming you should disable it in your environment, according to Dan Brown, lead security researcher at Bit9.
"But people aren't heeding the advice to remove it because they don't view it as being distinct from other vulnerable software. But Java is different, and there are reasons why it's favored by attackers," Brown said.
There are many different versions of Java and you can try to keep up with patches and updates, but the average organization has "more than 50 different versions of Java on their networks," Brown said. But "fewer than 1% of enterprises are running the latest version."
The most popular version of Java -- version 6, update 20 -- has 96 vulnerabilities that are rated a "perfect 10," according to Bit9's report. That's 96 as-severe-as-you-can-get vulnerabilities.
How quickly are these Java security vulnerabilities showing up? "Fast. Just in a matter of months, between version 7, update 21, and version 7, update 25, software installed everywhere had 38 severe vulnerabilities," Brown said.
While people have been banging on the "Java is bad" drum for quite a while already, Bit9 hopes to shine light on the fact that it isn't just bad; it's bad in a special way. "People don't understand that installing Java doesn't remove older versions. Make sure you upgrade, not install again. That's one of the reasons there are so many versions of Java on endpoints," Brown said.
Why is it bad to have older versions of Java on endpoints? "Java security vulnerabilities come in a couple of flavors," Brown explained. "One is a typical exploit that allows you to break out of the sandbox. The Java virtual machine (VM) running in a browser basically has an isolation sandbox layer around it. Attackers can find and use vulnerabilities to essentially convince Java to behave like a full-blown Java application -- with all the rights and privileges -- rather than being restricted to the in-browser sandbox."
Another vulnerability has to do with controls put in place by Oracle or others to warn users about the fact that the applet is attempting to get access to an older version of Java.
"An attacker can basically ask to have their code run on older, more vulnerable versions," Brown said. "It's a difficult problem, substantially different than the other types of vulnerabilities that organizations are used to dealing with. If every organization could flip a switch and get rid of Java vulnerabilities in their environment, they'd be substantially safer."
Java is a capable, functional black box
One thing that sets Java apart that tends to get glossed over from a threat perspective is that it's a capable, functional black box. When an attacker gains control of the Java VM, they have lots of capabilities -- including scripting.
If they can get one of the vulnerabilities to simply break out of the sandbox or give them elevated privileges in the VM, whatever code they want to download is executed by the Java VM, and their security controls have next to no visibility into that.
"Java's not like Adobe Acrobat, which is a fixed-function program that doesn't provide an attacker with many capabilities inherent to that software," Brown explained. "With Java, the attacker has all of the capabilities of the Java VM to use at their will, and they can do all of those things in the context of Java."
When people typically look for malware, executables that are bad, and they see just Java.exe, which we all love and trust, but wait -- it's running code internally. "The code inside is basically causing Java.exe to do all these malicious things," Brown said. "It's providing those capabilities, essentially making that a black box so security controls don't have visibility into it. That's something I don't think people know and it makes Java an easy target."
How can enterprises lower their risk of Java exploits?
Some enterprises can remove Java wholesale from their environments without seeing a real impact to their business. But for others, Java will be embedded in business uses cases for a long time.
"Enterprises may not have the resources to revamp old code they've written in Java," Brown said. "But you still need to pay attention to it and deal with it somehow. The first step is to find out how pervasive it is in your enterprise -- how many versions you have and where -- and figure out how many versions you can get rid of."
Another step is to remove exposure to the Web browser if you can. "Removing Java from the browser removes virtually all of the attack surface area," Brown said.
If you have business use cases for Java, especially if it has to run in the context of the browser, Bit9 recommends isolating that environment. "Give it special treatment with a sandbox browser or, better yet, use a VM or some isolation technology to truly isolate the Java on your desktop network," Brown noted.
Bottom line: Bit9 recommends removing Java if you can. If not, reduce exposure as widely across your organization as possible and isolate it if it absolutely has business case uses in your environment that you just can't live without.