Tuesday 25 March 2014

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.



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

Tuesday 4 March 2014

Running Java applications without installing Java

Although it seems to be a dying breed, there are still some Java client-side applications that you may want or need to use e.g. the excellent Burp Suite.  But this means having Java installed on your workstation - queue dramatic music.

This is less like handing over the keys to your computer than it used to be.  Java can be configured so that Java content is disabled in all browsers (at least from version 7 update 10 and higher).  But if the application requires an old version, or you just have little faith in the Swiss cheese that is Java's security controls, then it would be nice to isolate your Java installation.

There are several ways to isolate Java, from hardening its configuration to only running it in a virtual machine. What I'm going to suggest here is another option, using Java without installing Java.

This approach is already really common with server-side applications.  It is common for server-side applications to install themselves with their own copy of the Java runtime, as this means there is no danger of compatibility issues with the current shared install of Java on the server or any updates to it.  So why not take the same approach for client-side applications, and benefit from isolating Java to the one application that needs it.

So here's what to do (using Windows notation, but it's similar for non-Windows):
  1. Obtain the offline Java installation .exe
  2. Follow these instructions to get access to the Data1.cab file
  3. Unzip the Data1.cab to get the core.zip file
  4. Unzip the core.zip file to get the JRE files
  5. In the .\lib folder there are several .pack files, you need to unpack these to their .jar equivalents using unpack200.exe (in the .\bin folder) e.g. "..\bin\unpack200.exe -r rt.pack rt.jar".  Hat tip.
  6. (Optional) You can remove several files as they are usually unnecessary (importantly the browser plugin is one of them).  This makes the total size smaller, but not by much.
  7. Run you client-side Java application by directly invoking .\bin\java.exe
The JRE files come in at about 100Mb (for version 7 update 51) so I wouldn't necessarily be doing this separately for lots of applications.

I got this working for Burp Suite, but I didn't regression test all of its functionality, so whilst the method seems to work, I can't give any guarantees it does. YMMV.

Dave