Recent weeks have been full of commentary and discussions about the state of cyber security and the seemingly endless attacks that we are facing.
One of the greatest examples of insecure technology leading to businesses 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 an instance towards the end of last year where Oracle announced that Java 6.0 users would be force-updated to Java 7 starting in 2013. This news was followed by the discovery of a new zero-day vulnerability within Java, which in fact only affected Java 7. You could almost picture the Java lemmings marching forward off a cliff.
While these issues have been discussed with more frequency in the press recently, they 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 its products, it is one of the greatest examples of a large software company making the right moves to secure its 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 organisations 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.
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.
The potential security impact on small businesses
I realise one might make the argument that companies use centralised software-updating technologies for doing software patch management and, therefore, could query whether there really is a problem. 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 organisations that rely on the built-in software updating capabilities of applications and they should not be penalised because they implement a security best practice such as least-privilege.
There are options for those companies and home users who wish to work around this Java updating issue.
For example, configure Java Updater to use Windows 2000 compatibility settings.
The reason that Java does not properly update under Windows UAC has to do with its apparent usage of Microsoft’s BITS (Background Intelligence Transfer Service) and how Java handles BITS+UAC. Disabling BITS is not something we recommend, since doing so can impact built in Windows Update functionality as well as other applications that leverage BITS. One workaround is to set the Java Updater application to use Windows 2000 compatibility mode, which will make Java side step BITS and update normally, and therefore with success.
Individuals can search their system for ?jucheck.exe , typically found in the Program Files folder under Common FilesJavaJava Updatejucheck.exe. Once you have found the file you can right click, select Properties, Compatibility tab, click Change settings for all users button, check Run this program in compatibility mode for: Windows 2000, and then hit Ok to apply. Java should now be properly updating on a system without requiring the usage of an Administrator account.
Businesses can use GPO and automated registry settings to implement Windows 2000 application compatibility for Java Update in a more programmatic way.
This would look something like the following:
” Path: HKEY_LOCAL_MACHINESoftwareMicrosoftWindows NTCurrentVersionAppCompatFlagsLayers” Key: C:Program FilesCommon FilesJavaJavaUpdatejucheck.exe REG_SZ Value: WIN2000″ Path: HKEY_LOCAL_MACHINESoftwareMicrosoftWindows NTCurrentVersionAppCompatFlagsLayers” Key: C:Program Files (x86)Common FilesJavaJavaUpdatejucheck.exe REG_SZ Value: WIN2000
Another option is to download privilege management software. However, for any size company, security is a multi-faceted challenge and this is just one of many security issues of which to be aware, but at least it is one that with the right steps, companies can and should be able to give themselves better protection.
Brian Chappell is the director of engineering at BeyondTrust EMEA & India.
