Free Privileged Account Discovery Tool: Identify & secure credentials to stop lateral movement. Download Free

BeyondTrust
  • Products
    Privileged Password Management
    Discover, manage, audit, and monitor privileged accounts
    Password Safe DevOps Secrets Safe
    Endpoint Privilege Management
    Manage privileges on Windows, Mac, Linux, and Unix endpoints
    Windows and Mac Unix and Linux Active Directory Bridge
    Secure Remote Access
    Centrally manage and secure remote access for service desks and vendors
    Remote Support Privileged Remote Access
    BeyondInsight Analytics
    See All Solutions
  • Resources

    Universal Privilege Management

    Our innovative Universal Privilege Management approach secures every user, asset, and session across your entire enterprise.

    Watch Video

    Learn

    Case Studies
    Competitor Comparisons
    Datasheets
    Glossary
    Product Demos
    Whitepapers

    Attend

    Events
    Go Beyond
    Training
    Webinars

    Support

    Changelog
    Professional Services
    Technical Documentation
  • Blog
  • Partners
  • Contact
  • Support
  • Services
  • Training
  • Events
  • Company

Oracle's Java Hates Least-Privilege

March 9, 2013

  • Blog
  • Archive
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:

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

update_error_2

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.

compatibility_settings

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

Stay Up To Date

Get the latest news, ideas, and tactics from BeyondTrust. You may unsubscribe at any time.

I agree to receive product related communications from BeyondTrust as detailed in the Privacy Policy, and I may manage my preferences or withdraw my consent at any time.

You May Also Be Interested In:

Whitepapers

A Zero Trust Approach to Secure Access

Webcasts

Rising CISOs: Ransomware, Cyber Extortion, Cloud Compromise, oh my!

Whitepapers

A Zero Trust Approach to Windows & Mac Endpoint Security

BeyondTrust Logo
  • Facebook
  • Twitter
  • LinkedIn

Keep up with BeyondTrust

I agree to receive product related communications from BeyondTrust as detailed in the Privacy Policy, and I may manage my preferences or withdraw my consent at any time.

Customer Support
Contact Sales

Products

  • Endpoint Privilege Management
  • Password Management
  • Privileged Remote Access
  • DevOps Secrets Safe
  • Remote Support

Resources

  • Blog
  • Case Studies
  • Competitor Comparisons
  • Datasheets
  • Glossary
  • Videos
  • Webcasts
  • Whitepapers

About

  • Company
  • Careers
  • Contact
  • Events
  • Leadership Team
  • Partner Program
  • Press

Languages

  • English
  • German
  • French
  • Spanish
  • Korean
  • Portuguese
  • Japanese
  • Privacy
  • Security
  • Manage Cookies
  • WEEE Compliance

Copyright © 1999 — 2020 BeyondTrust Corporation. All rights reserved. Other trademarks identified on this page are owned by their respective owners. BeyondTrust Corporation is not a chartered bank or trust company, or depository institution. It is not authorized to accept deposits or trust accounts and is not licensed or regulated by any state or federal banking authority.