Oracle Will Make Java Security A Priority Going Forward

Developer & Design

Share this Post

To say Java is vulnerable to exploits would be the understatement of the year. In the first two months of 2013, the software was hit with three zero-day exploits. Oracle eventually fixed all of these exploits, but Oracle should have worked harder to make it more secure in the first place. In a better late than never move, the software maker will be doing just that.

Oracle announced in a blog post that it will align Java with its Critical Patch Update schedule in October of this year. In other words, Oracle will release four annual security fixes for Java instead of the three it releases now. For zero-days and other sudden exploits, Oracle will "retain the ability to issue emergency "out of band" security fixes."

The above is part of a larger push to move Java into the Oracle Software Security Assurance program. The hope is that this will help prevent "the introduction of new vulnerabilities in the Java code base." Oracle says that its developers will use more automated security testing tools alongside new analysis tools that will find certain types of vulnerabilities.

For consumers running Java on their browsers, Oracle will be introducing three changes into how it interacts with the browser:

  • (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.
  • On a final note, Oracle will also be increasing security for Java on servers to increase enterprise consumer trust in its services. The software maker points out that Java on servers is rarely affected by exploits, but it wants to take a better safe than sorry approach to the matter. It will do this by introducing what it calls Server JRE - a new Java distribution that removes vulnerable plugins. It will also work towards removing certain code libraries that are unnecessary for server distributions of Java.

    All of the above makes it sound like Oracle is taking Java security very seriously. Of course, words and actions are two different things so we'll have to see how Oracle reacts to emerging threats later this year when it implements its new security policies.