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.
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.
Sign up for CIO Asia eNewsletters.