Java's security problems unlikely to be resolved soon, researchers say

Security experts think Oracle should have acted sooner to strengthen Java against attacks

Since the start of the year, hackers have been exploiting vulnerabilities in Java to carry out a string of attacks against companies including Microsoft, Apple, Facebook, and Twitter, as well as home users. Oracle has made an effort to respond faster to the threats and to strengthen its Java software, but security experts say the attacks are unlikely to let up any time soon.

Just this week, security researchers said the hackers behind the recently uncovered MiniDuke cyberespionage campaign used Web-based exploits for Java and Internet Explorer 8, along with an Adobe Reader exploit, to compromise their targets. Last month, the MiniDuke malware infected 59 computers belonging to government organizations, research institutes, think tanks and private companies from 23 countries.

[ How to kill Java dead. | What the latest Java flaws really mean. | Developers: Java doesn't have to be unsafe. | After initial silence on Java flaws, Oracle said that it really does care. | Find out the latest from the Java realm with InfoWorld's Enterprise Java newsletter. ]

The Java exploit used by MiniDuke targeted a vulnerability that hadn't been patched by Oracle at the time of the attacks, Kaspersky Lab said in a blog post. Vulnerabilities that are made public or exploited before a patch is released are known as zero-day vulnerabilities, several of which have been used in the attacks against Java this year.

In February, software engineers from Microsoft, Apple, Facebook, and Twitter had their work laptops infected with malware after visiting a community website for iOS developers that had been rigged with a Java zero-day exploit. The breaches were the result of a larger "watering hole" attack launched from multiple websites that also affected government agencies and companies in other industries, The Security Ledger reported.

Oracle has responded to the attacks by issuing two emergency security updates since the start of the year and accelerating the release of a scheduled patch. It has also raised the default setting of the security controls for Java applets to high, preventing Web-based Java applications from executing inside browsers without user confirmation.

Security experts say this is a good start but think more should be done to increase the adoption rate for updates and to improve the management of Java security controls in corporate environments. More importantly, they say, Oracle should thoroughly review its Java code to identify and fix the basic security issues. They believe Java would be more secure today if Oracle had listened to the security industry's warnings over the years.

"It's difficult to say what has been going on internally at Oracle for the past years, but based on an external impression I feel they could have reacted sooner," said Carsten Eiram, chief research officer at consulting firm Risk Based Security, via email. "I'm not sure Oracle really took the predictions of Java being the next major target seriously."

It's unlikely Oracle could have prevented the recent attacks, he said, but it would be in a better position if it had acted sooner to secure its code and add more layers of security.

"I think the current state of Java security is due to the fact that Sun pushed Java very strongly when they still owned it," said Costin Raiu, director of the global research and analysis team at Kaspersky Lab, via email. "After Oracle purchased Java, perhaps little interest went into this project."

Oracle acquired Java when it bought Sun Microsystems in 2010. The software is installed on 1.1 billion desktop computers worldwide, according to information at Its widespread deployment and cross-platform nature make it an attractive target for hackers. Researchers at Security Explorations, a Polish vulnerability research firm, have found and reported 55 vulnerabilities in the Java runtimes maintained by Oracle, IBM, and Apple over the past year, 36 of them in Oracle's version.

"In April 2012, we reported 30 security issues to Oracle affecting Java SE 7," Adam Gowdiak, Security Explorations' founder, said via email. "This was around the same time the Flashback Mac OS trojan was found in the wild. Both should have worked as a wake up call for Oracle."

Kaspersky Lab has reported that at any given time last year, one in three users was running a version of Java that was vulnerable to one of five major exploits being used by hackers. At peak times, more than 60 percent of users had a vulnerable Java version installed.

Providing a silent, automatic update mechanism like that found in Chrome, Flash Player, Adobe Reader, and other software might be helpful to consumers, Eiram said. However, businesses will probably disable such features, he said.

Starting with Java 7 Update 10, released in December, Oracle has provided new options in the Java control panel that allow users to disable the Java plug-in from browsers or force Java to ask for confirmation before Java applets execute. Since Java 7 Update 11, the default setting for this mechanism has been set to high, preventing unsigned Java applets from running automatically without user confirmation.

"I believe the new security features in Java show that Oracle is moving in the right direction," said Wolfgang Kandek, CTO of Qualys, which sells vulnerability management and policy compliance products. Making Java even more configurable would help IT administrators to deploy it in a manner that meets the requirements of their organizations.

"I would welcome white-listing capabilities in Java, i.e., prohibiting all but approved sites to use the applet mechanism," Kandek said. "At the same time, central management of the Java configuration capabilities, i.e., via Windows GPO [Group Policy], should be improved."

Kandek believes Oracle faces a bigger challenge in hardening Java against attacks than other software companies did with their own products. "Java is a complete programming language and needs to be able to perform the full gamut of actions ... including low-level operating system tasks."

That said, Eiram and Gowdiak both said Oracle needs to improve the quality of its Java code from a security perspective, because right now it's relatively easy to find vulnerabilities.

"Software vendors have a responsibility to provide secure code of a certain quality, and vendors of widely deployed software like Flash Player or Java simply have no excuse," Eiram said. "Adobe realized this and have made a serious and successful effort to improve their code. Microsoft did the same many years ago. It's time for Oracle to follow in those footsteps."

There are indications that Oracle's developers are unaware of Java's security pitfalls and that code security reviews are either not done at all or not comprehensive enough, Gowdiak said. Many of the issues identified by Security Explorations violate Oracle's own secure coding guidelines for Java, he said.

"We found many flaws which should have been eliminated by the company at the time of a comprehensive security review of the platform prior to its release," Gowdiak said.

Oracle should implement a solid Secure Development Lifecycle for Java to weed out basic vulnerabilities and increase the code's maturity, Eiram said. An SDL is a software development process that emphasizes code security reviews and secure development practices to reduce vulnerabilities.

The best approach would be to ensure developers are properly trained by holding internal training sessions, as Microsoft did, and to review the existing code with help from external auditors, Eiram said. "Oracle might as well contract some of the skilled researchers who are looking at their code anyway."

Oracle has said it would accelerate the patching cycle for Java from 4 months to 2 months and promised to communicate better about Java security issues with all audiences, including consumers, IT professionals, the press and security researchers. The long intervals between Java security updates and Oracle's lack of communication on security have long been criticized.

"It will be interesting to see if they will honor their promise of communicating better with the public and press. In the past, they have -- in my opinion -- been downright arrogant and refused to comment on reported vulnerabilities, and even their validity," Eiram said.

The policy of not commenting on security issues, which Oracle said was necessary to protect users, resulted in users not knowing if externally reported threats were real or what Oracle was doing about them, he said. "This approach to security and responsiveness belongs in the previous millennium."

Security experts don't expect Oracle to solve all the problems in the near future in a way that will deter determined attackers.

"I do not foresee Java's security problems ending any time soon," Eiram said. "It took both Microsoft and Adobe a while to turn the boat around, and their products are still subject to zero-day [exploits] now and then. Java has a lot to offer attackers, so I expect them to keep their focus on it for now."

"I would not expect solutions any time soon," Kandek said. "IT administrators should invest their time in understanding where they need Java on the desktop and where they can restrict it."

Security experts agree that Java should be disabled where it's not needed, at least at the browser level. Many users don't even know they have Java installed on their computers. That's probably why Google and Mozilla chose to restrict the Java plug-in in Chrome and Firefox, Raiu said.

Apple has also blacklisted vulnerable versions of the Java plug-in on Mac OS X, and Windows has a registry setting that can limit Java use in Internet Explorer to trusted websites.

While many home users don't need Java in their browsers, people in some parts of the world might. In Denmark, for example, online banking and government websites use a log-in mechanism called NemID that requires Java support, Eiram said. Similar cases might exist in other countries.

In those cases, using the click-to-play feature in Chrome and Firefox, or the Zones mechanism in IE, could be used to let Java content load from only certain websites. A less technical solution would be to use one browser with Java disabled for general tasks, and a different browser with Java enabled for trusted websites that need Java support.

Restricting the use of Java in corporate environments is more difficult. Many companies use internal and external Web-based applications that require the Java browser plug-in to run. Features like click-to-play are not suitable for corporate environments where policies need to be centrally managed and enforced.

"Making Java more configurable will help IT administrators deploy Java in the right fashion for the organization's requirements," Kandek said. "Higher default security levels and the easy disconnect from the browser are a good start, but I believe we will need to improve the white-listing capabilities of browsers or the Java plug-ins."

For the moment, the Zone mechanism in IE offers the most scalable management capabilities for the Java plug-in in corporate environments, Kandek said.

The recent wave of Java-based attacks, including the one that resulted in security breaches at Microsoft, Facebook, Apple, and Twitter, might have damaged Java's reputation, Eiram said. But if businesses had confidence in Java as being safe and secure, "they haven't been heeding the plentiful warnings provided by researchers for a while," he said.

It's not only Java's reputation that might have been damaged. It's likely some companies are asking whether Java's poor security is reflected in other Oracle products, Gowdiak said.

Eiram hopes the recent attacks will cause companies to re-evaluate whether they need Java in their environments.

"Companies in general are migrating to pure HTML5 based applications and moving away from plug-ins like Flash, Silverlight, and Java," Kandek said. "Java will continue to grow on the server side, where its powerful processing capabilities are absolutely needed."

Copyright © 2013 IDG Communications, Inc.

How to choose a low-code development platform