Nandini Ramani, leader of Oracle’s Java development, wrote an interesting blog post last week here on all the security vulnerabilities that have been plaguing Java here recently. Actually it was more of a defense of “Hey, it’s hard writing software and we have to follow these procedures that are REALLY complicated”. Let’s look at some of what was said…..

Over the past year, there have been several reports of security vulnerabilities in Java, primarily affecting Java running in Web browsers.

Well, it hasn’t been just reports. That makes it sound like a bigfoot sighting or something. These were very serious security holes that Oracle tried to not respond to and just release patches as quickly as possible. Like those horror movies were the woman is hunkered down in the closet with the baddie in the bedroom saying “please don’t find me….please don’t find me”.

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.

Well, except that Oracle has owned Java since 2009. Sorry guys it’s 2013 and these procedures should be much more fluid. That and the fact that the rapidness of these security holes showing up means that either

A.) You’re writing crappy code

B.) Your security testing needs to be upped a bit

Literally bragging that you have made about twice as many security fixes in the first half of 2013 than you did in ALL of 2012(58 in 2012 … 97 this year so far) isn’t exactly comforting. Add to the fact that it then states that NOW they are making expanded use of automated security testing tools and you see that things have been pretty lax in that group.

Then you have to read a little further into Oracle’s idea of making everything secure again…..especially points #2 and #3

  (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.

So basically these are tied to signing java applets. The important thing to note is that soon every applet will need to be signed, AND will not allow self-signed code. My question is …. What about our development environments? I have to think that if they are locking down the self-signed certificates…then we will no longer be able to use a .java.policy file. I mean right or am I missing something here?

I may seem to be a little harsh on Oracle here, and for good reason. If this had been Microsoft this year then they would have been EXCORIATED. Plus for years, it has been a constant drumming of how Java….more secure than .NET…better than .NET ….portability….blah blah blah. I guess it is fairly portable because as this year has shown….. Oracle makes your Java code vulnerabilities totally portable between platforms.