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.
- 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
- Download free community versions of our Privilege Management software, PowerBroker Desktops, to help better enable a least-privilege computing scenario and our Vulnerability Management software, Retina CS, which includes free vulnerability identification and patch management capabilities for Microsoft software, as well as third party applications including Java. Community version of Retina CS allows scanning as many as 256 assets.
Download the community version of Retina CS allows scanning as many as 256 assets.

Scott Lang, Sr. Director, Product Marketing at BeyondTrust
Scott Lang has nearly 20 years of experience in technology product marketing, currently guiding the product marketing strategy for BeyondTrust’s privileged account management solutions and vulnerability management solutions. Prior to joining BeyondTrust, Scott was director of security solution marketing at Dell, formerly Quest Software, where he was responsible for global security campaigns, product marketing for identity and access management and Windows server management.