Maintaining the security-worthiness of Java is Oracle’s priority
By Eric P. Maurice on May 30, 2013
Hi my name is Nandini Ramani, I lead the software development team building the Java platform. My responsibilities span across the entire Java platform and include platform security.
Over the past year, there have been several reports of security vulnerabilities in Java, primarily affecting Java running in Web browsers. This blog entry outlines the steps Oracle has taken to address issues with the security-worthiness of Java in web browsers and elsewhere following the acquisition of Sun Microsystems.
Whenever Oracle makes an acquisition, acquired product lines are required to conform to Oracle policies and procedures, including those comprising Oracle Software Security Assurance. As a result, for example, the Java development organization had to adopt Oracle’s Security Fixing Policies, which among other things mandate that issues must be resolved in priority order and addressed within a certain period of time.
As a result of adopting these stricter procedures, as well as increasing investments in Java overall by Oracle, Java development significantly accelerated the production of security fixes. Recently-released Critical Patch Updates for Java SE have contained a historically high number of security fixes. In addition, Oracle decided to publish an additional security release in 2013. The April 2013 Critical Patch Update for Java SE will bring Java to four security releases in 2013 as opposed to the three initially planned. As a reminder, the February 2012 Critical Patch Update for Java SE provided 14 security fixes, the June 2012 release 14, the October 2012 release 30 (thus the total number of new security fixes provided through Critical Patch Updates for Java in 2012 was 58). In contrast to these numbers, the February 2013 security releases provided 55 new security fixes, and the April 2013 Critical Patch Update for Java SE provided 42 new security fixes, bringing the total number of security fixes released through the Critical Patch Update for Java in the first half of 2013 to 97.
In addition to accelerating the release of security fixes for Java SE, Oracle’s additional investments have provided the organization with the ability to more quickly respond to reports of 0-days and other particularly severe vulnerabilities. Java development has gained the ability to produce and test individual security fixes more quickly as evidenced by the quick releases of the most recent Java Security Alerts. In other words, the procedural and technical changes implemented throughout Java development have enabled the organization to make improvements affecting both the Critical Patch Update program (scheduled release of a greater number of security fixes) and the Security Alert program (faster release of unscheduled security fixes in response to 0-days or particularly severe vulnerabilities).
Starting in October 2013, Java security fixes will be released under the Oracle Critical Patch Update schedule along with all other Oracle products. In other words, Java will now issue four annual security releases. Obviously, Oracle will retain the ability to issue emergency “out of band” security fixes through the Security Alert program.
The implementation of Oracle Software Security Assurance policies and practices by Java development is also intended to defend against the introduction of new vulnerabilities into the Java code base. For example, the Java development team has expanded the use of automated security testing tools, facilitating regular coverage over large sections of Java platform code. The Java team has engaged with Oracle’s primary source code analysis provider to enhance the ability of the tool to work in the Java environment. The team has also developed sophisticated analysis tools to weed out certain types of vulnerabilities (e.g., fuzzing tools).
Oracle is also addressing the limitations of the existing Java in browser trust/privileges model. The company has made a number of product enhancements to default security and provide more end user control over security. In JDK 7 Update 2, Oracle added enhanced security warnings before executing applets with an old Java runtime. In JDK 7 Update 6, Oracle began dynamically updating information about security baselines – information used to determine if the current version of Java contains the latest security fixes available. In JDK 7 Update 10, Oracle introduced a security slider configuration option, and provided for automatic security expiration of older Java versions (to make sure that users run the most recent versions of Java with a more restricted trust model than in older versions). Further, with the release of JDK 7 Update 21, Oracle introduced the following changes:
(1) The security model for signed applets was changed. Previously, signing applets was only used to request increased application privileges. With this update, signing applets establishes identity of the signer, but does not necessarily grant additional privileges. As a result, it is now possible to run signed applets without allowing them to run outside the sandbox, and users can prevent the execution of any applets if they are not signed.
(2) The default plug-in security settings were changed to further discourage the execution of unsigned or self-signed applets. This change is likely to impact most Java users, and Oracle urges organizations whose sites currently contain unsigned Java Applets to sign those Applets according to the documented recommendations. Note, however, that users and administrators will be able to specifically opt out of this setting and choose a less secure deployment mode to allow for the execution of unsigned applets. In the near future, by default, Java will no longer allow the execution of self-signed or unsigned code.
(3) While Java provides the ability to check the validity of signed certificates through Certificate Revocation Lists (CRLs) or Online Certificate Status Protocol (OCSP) calls before the execution of signed applets, the feature is not enabled by default because of a potential negative performance impact. Oracle is making improvements to standardized revocation services to enable them by default in a future release. In the interim, we have improved our static blacklisting to a dynamic blacklisting mechanism including daily updates for both blacklisted jar files and certificates.
Finally, while the security problems affecting Java in Internet browsers have generally not impacted Java running on servers, Oracle has found that the public coverage of the recently published vulnerabilities impacting Java in the browser has caused concern to organizations committed to Java applications running on servers. As a result, Oracle is taking steps to address the security implications of the wide Java distribution model, by further dissociating client/browser use of Java (e.g., affecting home users) and server use (e.g., affecting enterprise deployments). With Java 7 update 21, Oracle has introduced a new type of Java distribution: “Server JRE.”
Oracle has removed plugins from the Server JRE distribution to reduce attack surface but also to reduce customer confusion when evaluating server exploitation risk factors. In the future, Oracle will explore stronger measures to further reduce attack surface including the removal of certain libraries typically unnecessary for server operation. Such significant measures cannot be implemented in current versions of Java since they would violate current Java specifications, but Oracle has been working with other members of the Java Community Process to enable such changes in future versions of Java.
In addition, Oracle wants to improve the manageability of Java in enterprise deployments. 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. 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.
It is our belief that as a result of this ongoing security effort, we will 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. Oracle’s effort has already enabled the Java development team to deliver security fixes more quickly, resulting in fewer outstanding security bugs in Java.
For more information:
More information about Oracle Software Security Assurance is located at http://www.oracle.com/us/support/assurance/index.html
Java security documentation is located at http://www.oracle.com/technetwork/java/javase/tech/index-jsp-136007.html
Release notes for JDK 7 releases are located at http://www.oracle.com/technetwork/java/javase/7u-relnotes-515228.html