Oracle reveals plans for Java security improvements

Oracle plans to make changes to strengthen the security of Java, including fixing its certificate revocation checking feature, preventing unsigned applets from being executed by default and adding centralized management options with whitelisting capabilities for enterprise environments.

These changes, along with other security-related efforts, are intended to “decrease the exploitability and severity of potential Java vulnerabilities in the desktop environment and provide additional security protections for Java operating in the server environment,” said Nandini Ramani, vice president of engineering for Java Client and Mobile Platforms at Oracle, in a blog post on Thursday.

Ramani’s blog post, which discusses “the security worthiness of Java,” indirectly addresses some of the criticism and concerns raised by security researchers this year following a string of successful and widespread attacks that exploited zero-day — previously unpatched — vulnerabilities in the Java browser plug-in to compromise computers.

Ramani reiterated Oracle’s plans to accelerate the Java patching schedule starting from October, aligning it with the patching schedule for the company’s other products, and revealed some of the company’s efforts to perform Java security code reviews.

“The Java development team has expanded the use of automated security testing tools, facilitating regular coverage over large sections of Java platform code,” she said. The team worked with Oracle’s primary provider of source code analysis services to make these tools more effective in the Java environment and also developed so-called “fuzzing” analysis tools to weed out certain types of vulnerabilities.

The apparent lack of proper source code security reviews and quality assurance testing for Java 7 was one of the criticisms brought by security researchers in light of the large number of critical vulnerabilities that were found in the platform.

Ramani also noted the new security levels and warnings for Java applets — Web-based Java applications — that were introduced in Java 7 Update 10 and Java 7 Update 21 respectively.

These changes were meant to discourage the execution of unsigned or self-signed applets, she said. “In the near future, by default, Java will no longer allow the execution of self-signed or unsigned code.”

Such default behavior makes sense from a security standpoint considering that most Java exploits are delivered as unsigned Java applets. However, there have been cases of digitally signed Java exploits being used in the past and security researchers expect their number to increase.

Because of this it’s important for the Java client to be able to check in real time the validity of digital certificates that were used to sign applets. At the moment Java supports certificate revocation checking through both certificate revocation lists (CRLs) and the Online Certificate Status Protocol (OCSP), but this feature is disabled by default.

“The feature is not enabled by default because of a potential negative performance impact,” Ramani said. “Oracle is making improvements to standardized revocation services to enable them by default in a future release.”

The company is also working on adding centrally managed whitelisting capabilities to Java, which will help businesses control what websites are allowed to execute Java applets inside browsers running on their computers.

Unlike most home users, many organizations can’t afford to disable the Java browser plug-in because they need it to access Web-based business-critical applications created in Java.

“Local Security Policy features will soon be added to Java and system administrators will gain additional control over security policy settings during Java installation and deployment of Java in their organization,” Ramani said. “The policy feature will, for example, allow system administrators to restrict execution of Java applets to those found on specific hosts (e.g., corporate server assets, partners, etc.) and thus reduce the risk of malware infection resulting from desktops accessing unauthorized and malicious hosts.”

Even though the recent Java security issues have generally only impacted Java running inside browsers, the public coverage of them has also caused concern among organizations that use Java on servers, Ramani said.

As a result, the company has already started to separate Java client from server distributions with the release of the Server JRE (Java Runtime Environment) for Java 7 Update 21 that doesn’t contain the browser plug-in.

“In the future, Oracle will explore stronger measures to further reduce attack surface including the removal of certain libraries typically unnecessary for server operation,” Ramani said. However, those changes are likely to come in future major versions of Java since introducing them now would violate current Java specifications, she said.