Making Java RIAs MIA - Enterprise Style

This post is all about how to disable Java in the browser, or alternative making Java Rich Internet Applications (RIA) missing-in-action.  There is a lot of information out there on how to do this, but I couldn't find a good source that covered it from an Enterprise point of, that is, how to disable Java in the browser at scale (rather than just doing it on our own machine using a GUI), across multiple browsers and OSes.

First let's cover the obvious, why do we want to do this.  See my page on Java Vulnerabilities.  Basically if Java is enabled in your browsers then you are opening yourself up to a world of pain.  If you have Java enabled in your browsers then you have malware somewhere in your Enterprise.

What we want is to understand the options we have for disabling Java in the browser and understand what the settings are that we need to configure.

Browser Agnostic
Uninstall Java

This is obviously a good option as it removes the risk of Java.  However, depending on your environment user's may just re-install Java, so unless you are actively scanning for Java installations your Enterprise this approach might not be as effective as you'd like it to be.

For that reason I'm not going to focus on this solution too much, but for non-Windows machines see Oracle's advice on uninstalling and this post.

For Windows you can detect the installed versions of Java using

wmic product where "name like 'Java%'" get name

and uninstall these via

wmic product where "name like 'Java%'" call uninstall

Java Deployment Options

From Java version 7 update 10 a deployment option exists to disable Java content in all browsers (these are the same options as available in the Java Control Panel).  This option is a feature of Java and so is available on both Windows and non-Windows OSes.

The option is stored in a deployment.properties file.  The user has their own version of this file stored at (on Windows and non-Windows respectively):

<user_profile>\AppData\LocalLow\Sun\Java\Deployment\deployment.properties

<user home>/.java/deployment/deployment.properties

A system version, containing the default values for all users, can be created and stored at (on Windows and non-Windows respectively):

%WINDIR%\Sun\Java\Deployment\deployment.properties

/etc/.java/deployment/deployment.properties

This system version is only used by Java if a deployment.config file exists at (on Windows and non-Windows respectively):

%WINDIR%\Sun\Java\Deployment\deployment.config

/etc/.java/deployment/deployment.config

and contains an option that specifies the location of the system deployment.properties to use e.g. on Windows:

deployment.system.config=file\:C:/WINDOWS/Sun/Java/Deployment/deployment.properties

deployment.system.config.mandatory=true

The system version contains the default values that the user version will use, but the user can override these.  That is unless the system version indicates that the option should be locked (which means the user cannot change the option).

So to disable the plugin across all browsers and users the system deployment.properties should contain:

deployment.webjava.enabled=false

deployment.webjava.enabled.locked

Both the system deployment.config and deployment.properties should be ACL’ed so that the user cannot edit them (but can read them).

Although this option only applies from Java version 7 update 10, there is no issue in settings this option for earlier versions of Java, as the setting is ignored.  The benefit is that should Java be upgraded then this setting will be adopted.

Browser Specific

Internet Explorer (IE)

In response to the threat posed by Java in the browser Microsoft released a FixIt solution that disables Java in IE - http://support.microsoft.com/kb/2751647

The executable disables Java in the browser and appears as “IE Java Block 32bit Shim” in the list of installed programs.  Presumably the FixIt installs a 64bit equivalent on 64bit versions of IE.

We can detect if the Microsoft FixIt is installed by confirming that the following registry exists

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{01cf069a-f8a1-4067-adc4-5ef7e922733c}.sdb

If the Windows OS is 64-bit and 32-bit IE is installed then the key will be under:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall

There is some debate about the effectiveness of this FixIt.  Advice from CERT states that it doesn't completely prevent RIAs from being invoked by IE.  Alternative methods to disable Java exist that may be more reliable but seem to involve updating a list of blocked ActiveX controls with every release of Java.  You'll have to decide on the risk yourself, but on Windows perhaps unnstalling Java or using the Java deployment options are the safest options.

Firefox

Firefox has a configuration option that controls whether the plugin is enabled.  The option can be viewed by going to about:config and is called “plugin.state.java”.  It can take one of three values:

• 0 = disabled
• 1 = click to play
• 2 = enabled

The value of this option is stored in a file called “prefs.js” in the user’s Firefox profile directory.  If a user was to set this option via about:config their selection would be saved in this file.

It’s preferably to enforce all users (and all user profiles) to disable the plugin.  Firefox supports a ‘lock’ on the preference so that the user cannot (easily) change the option and enable the plugin (see Locking preferences).  By creating a file called “mozilla.cfg” in the installation directory of Firefox with the entry:

//

lockPref("plugin.state.java", 0);

Firefox needs to be instructed to load this lock file and this is done by creating a “local-settings.js” file in the “defaults\pref” sub-directory of the Firefox installation directory with:

pref("general.config.obscure_value", 0);

pref("general.config.filename", "mozilla.cfg");

With these configuration files and options in place the option plugin.state.java in about:config will be italicized and greyed out.

To prevent a user from changing “mozilla.cfg” and “local-settings.js” these files should be ACL’ed so that the user cannot edit them (but can read them).

I think I am not sure of is in what version of Firefox the plugin.state.java configuration was introduced, or even the ability to lock configuration options.  If your Enterprise is using a very old version of Firefox then this approach might not be available.

Reference -  http://stealthpuppy.com/prepare-mozilla-firefox-for-enterprise-deployment-and-virtualization/

Chrome

This method applies to Google Chrome and Chromium (with minor differences).  Chrome supports configuration via Policy  (see chrome://policy) and the policy value we want to set is called DisabledPlugins (see list of plugins via chrome://plugins/).

The DisabledPlugins policy can be overridden by the EnabledPlugins and DisabledPluginsExceptions policies though, so these policies also need to be set to ensure the Java plugin is disabled.

Windows

Chrome policy can be enforced via Group Policy.  Google provides ADM/ADMX templates.  The GPO should be configured at the "Computer Configuration" level:

• To set the DisabledPlugins policy, the policy entry “Specify a list of disabled plug-ins” should be set to “Enabled” and an entry of “Java(TM)” should be added.
• To set the EnabledPlugins policy, the policy entry “Specify a list of enabled plug-ins” should be set to a random value. (1)
• The set the DisabledPluginsExceptions policy, the policy entry “Specify a list of plug-ins that the user can enable or disable” should be set to a random value. (1)

Chrome historically supported policy configuration through the registry but this ability was removed in version 28.  The current policy is still written to the registry though, so this provides a mechanism to verify the policy exists on a machine.

Non-Windows

Chrome also supports configuration via policy on Non-Windows machines via a local JSON file containing the policy configuration.  The policy files live under /etc/opt/chrome for Google Chrome (and /etc/chromium for Chromium).

Two types of policies exist; "managed", which are mandatory policies, and "recommended" which are not mandatory.  These policies are respectively located under:

/etc/opt/chrome/policies/managed/

/etc/opt/chrome/policies/recommended/

To disable the Java plugin create a file “policy.json” in /etc/opt/chrome/policies/managed/ with the contents:

{

“DisabledPlugins”:["Java(TM)"],

“DisabledPluginsExceptions”:[" "],

“EnabledPlugins”:[" "],

}

The policy file should have ACLs applied to it so that users cannot edit (but can read) it.

(1) So why do we assign the EnabledPlugins and DisabledPluginsExceptions random values (or a space character)?  Turns out if we set these policies to "Not configured" or "Disabled" then a user can enable Java in the browser by configuring these policies in the "User Configuration" policy section.  If this seems like a security issue to you, well it seemed like one to me as well, that's why I opened a bug with Google about it.  They didn't really agree, but I concede it's complicated (and potentially it's a bug in Microsoft's Group Policy functionality).