Oracle's Java Hates Least-Privilege

Recently, there has been a lot of commentary and discussions about what to do about the state of security and the seemingly endless attacks that we are facing. There are, of course, many recommendations that are being made at a governmental level of how best to approach this problem through the use of information sharing and other high level tactics. However, little conversation is being had about what can be done to force technology companies into being more proactive about the security of their solutions. As Washington politicians continue to search for answers, they miss out on the crucial fact that we still have far too many technology companies producing insecure software and as long as that is happening it will remain extremely difficult to safeguard computer networks. One of the greatest examples of insecure technology leading to organizations being compromised is Oracle’s Java. Java has had a steady stream of security vulnerabilities for many years now, and in the last year, the severity of vulnerabilities has only increased. This has even caused companies like Apple to toggle Java off in versions of their OS X operating system. There was even an instance towards the end of last year where Oracle announced that Java 6.0 users would be forced updated to Java 7 starting in 2013. This news was followed by the discovery of a new zeroday vulnerability within Java that in fact only affected Java 7. You could almost picture the Java lemmings being marched forward off a cliff. While these issues have been discussed with more frequency in the press recently, the issues are nothing new. Microsoft is the greatest example of a company that suffered major blows over the years for the insecurity of their software and changed their trajectory shortly after Bill Gates wrote his Trustworthy Computing memo. While Microsoft still suffers many security issues in their products, they are one of the greatest examples of a large software company making the right moves to secure their products, if not second to Google. But while Microsoft developers and security professionals got the memo, the rest of the software industry seems to have missed it. Certainly Sun and now Oracle missed the memo as it relates to Java’s security. The issues with Java are not just ones of code security quality but also of fundamentally breaking important security best practices such as least-privilege; the process by which organizations and even home users ensure they are not always running with Administrator privileges. More specifically, Java’s updating system does not function when used in a least-privilege environment. If you attempt to run Java’s update functionality without Administrator access (under Windows) you will be prompted with a Microsoft UAC (User Account Control) dialogue to enter your Administrative credentials:

Upon entering your credentials you will eventually be met with the Update Available screen and after clicking the Install button you will get a failure message and the inability to update Java using this mechanism.

This is actually a known issue that has seen many complaints on various Internet forums and also even has a formal bug opened within Oracle’s online Bug Database since March of 2011. Note: The screenshots show testing against a Java 6.x code branch but Java 7.x was tested to have the same update behavior. The comments section of that bug report include a note that says “A limited user is not allowed to update Java.” It is not clear who wrote that comment but the wording shows a lack of understanding of the security principles at hand. It is commonplace for software companies that are doing the right things with security to allow for their software updating functionality to work properly even if you are not currently logged on as an Administrator privileged user. Google is an example of such a company doing that properly with Google’s Chrome. I realize one might make the argument that companies use centralized software updating technologies for doing software patch management and because of that, who cares about this issue? But beyond the fact that an issue like this clearly shows further lack of security process and design within the Java software ecosystem, there is also the simple fact that not every small and medium business has the time or money to implement a perfect patch management system to make up for something like Java’s shortcomings. There are still many organizations that rely on the built-in software updating capabilities of applications and they should not be penalized because they implement a security best practice such as least-privilege. Here are a few options for those companies and home users who wish to work around this Java updating issue.