Despite the significant Java security improvements made by Oracle during the past six months, Java vulnerabilities continue to represent a major security risk for organisations because most of them have outdated versions of the software installed on their systems, according to a report by security firm Bit9.
Bit9’s report was released Thursday and is based on data about Java usage collected from approximately 1 million enterprise endpoint systems owned by almost 400 organisations that use the company’s software reputation service.
The data shows that Java 6 is the most prevalent major version of Java in enterprise environments, present on more than 80 percent of enterprise computers that have Java installed.
Java 6 reached the end of public support in April, and only Oracle customers with a long-term support contract will continue to receive security updates for it. Java 7, the version that is the focus of Oracle’s recent security strengthening efforts, was only found on around 15 percent of endpoint systems sampled by Bit9.
Furthermore, most companies that run Java 6 on their systems don’t have the latest security updates for it, the security firm found.
The most widely deployed Java version, according to Bit9’s data, was Java 6 Update 20, which was installed on a little over 9 percent of endpoints. This version of Java is vulnerable to a total of 215 security issues, 96 of which have the maximum impact score on the Common Vulnerability Scoring System (CVSS) scale, Bit9 said.
The last publicly available security update for Java 6 is Java 6 Update 45, which was released in April at the same time as Java 7 Update 21, the latest version of Java available when Bit9 collected data for its report.
Only 3 percent of enterprise endpoint systems were running Java 7 Update 21, the company said. However, those endpoints belonged to only 0.25 percent of the sampled organisations, which seems to indicate that organisations with a larger number of endpoints are more likely to have the latest version of Java installed on their systems.
Another issue is that many enterprise systems have multiple versions of Java running on them. Around 65 percent of systems had more than two versions of Java installed at the same time, and approximately 20 percent had more than three versions.
According to Bit9’s report, on average, organisations have more than 50 distinct versions of Java installed in their environments. About 5 percent of organisations have more than 100 versions.
This problem mainly stems from how the Java installation and updating process deals with older versions.
The Java 7 updater will attempt to remove existing installations of Java 6, but a clean installation of Java 7 won’t remove older versions, said Harry Sverdlove, Bit9’s chief technology officer. Java 5 versions are not removed during Java 7’s installation or update processes, he said.
The Bit9 data showed that 93 percent of organisations have a version of Java on some of their systems that’s at least five years old. Fifty-one percent have a version that’s between five and 10 years old.
The problem with having multiple versions of Java installed at the same time on a system is that attackers can target the older and vulnerable versions to hack into that computer. Once that happens, the security of the newer Java versions doesn’t help.
Code that enumerates all Java versions installed on a system for reconnaissance purposes has already been seen in real attacks, Bit9 said in the report.
Having different Java versions on a system increases usability because customers can run legacy applications, but from a security perspective it’s a nightmare, Sverdlove said. Every version that is installed introduces yet another set of known vulnerabilities that attackers can target, he said.
Sverdlove compared the situation of companies running five-to-10-year-old versions of Java to running Windows 95. This practice might be convenient for compatibility reasons, but it’s a horrible security risk, he said.
In most cases, this kind of Java version fragmentation inside enterprise environments is probably not even intentional, as many companies don’t understand or keep track of how many versions they have installed, Sverdlove said.
First and foremost, organisations should get an assessment of what Java versions they have in their environments and where, Sverdlove said. The next step should be for them, as a matter of security policy, to stop and seriously consider whether they need Java, and if they do, for what purposes, he said.
The results of this assessment will vary among organisations, Sverdlove said. Some companies might find that a particular version of Java is needed to run legacy applications, but only on certain computers. Others might discover that certain websites that require Java work with the latest version of the software, and some might find that Java is only needed on their servers and not on desktops, he said.
Regardless of their individual Java needs, organisations should create a Java deployment policy and enforce it, Sverdlove said. If their policy is to not have Java, then they should use tools to block it from running; if they determine that they only need Java on certain machines, then they should remove it from all other machines, he said.
The most common way for hackers to attack Java installations is through the software’s Web browser plug-ins by using exploits hosted on websites.
The Bit9 report did not contain specific information about how many of the Java installations identified on enterprise endpoints were accessible through the Web browsers on those computers. However, the majority of the sampled endpoint systems were desktops and laptops, so the likelihood of those Java installations being exposed to Web attacks is high, Sverdlove said.
