Pushing Security Configuration for Java 7 Update 10 via GPO

NOTE: Please use the following blog post with improved solution http://www.darkoperator.com/blog/2013/1/14/centralized-management-of-java-se-environment-using-gpo-redu.html

A friend of mine that work on a local government agency called me quite concerned about the new Java Exploit that surfaced this month for Java 7u10, specially since he a lot of his CRM and HR systems depend on Java being Up and Running for the Oracle Solution he uses at work. He has always been quite concerned about the security of his hosts pushing Microsoft EMET on his windows boxes, Running the latest version of Java and uninstalling the old ones, having his machines up to date in patches and just all around good administration. He asked me if I could help him out find a way to force security to Very High on the the Java configuration and deploy it to all of his Windows 7 machines, so I took it as a challenged and the good guy in me said I would do it for free…. has this been a long afternoon of testing but finally got it.

JavaSE 1.7 update 10 allows for the configuration of its setting via a file called deployment.properties that can either reside in the user %APPDATA% folder under Sun\Java\Deployment or as a System Wide Setting under %WINDIR% folder under Sun\Java\Deployment so I took it to come up with a GPO Object for him that I could use with the settings he wanted to make sure as to mitigate the vulnerability and allow the teams inside his organization to use it while disabling Java to other via other settings.

The first step is to log in to a machine with Java and in the Java Control Panel configure the security level and in Advanced Settings the additional settings

This generated for us a file called deployment.properties that we can use as the master file to push to our Windows Clients.  The file is located under %USERPROFILE%\AppData\LocalLow\Sun\Java\Deployment The file is just a simple text file that we can then manipulated and add other entries to it. We now copy this file to a share that is accessible to all machines and that the file is readable to machine accounts in the domains since the connections to the share will be done by them.

The main lines you will want are:

deployment.security.askgrantdialog.notinca=false
deployment.security.level=VERY_HIGH

This will block none trusted Applets and will prompt the user for automatic applet download. If you want you can create a second one to block Java on all browsers by making sure the file contains:

deployment.webjava.enabled=false

On one of our domain controller we open the Group Policy Management administration tool. We right click on the Group Policy Objects node in the right side and select New in the menu

We give it a descriptive name

We Right-Click on the newly created Policy and choose Edit from the menu

We now navigate to Computer Configuration –> Preferences –> Windows Settings –> Files

We select the Action of Create, put in the Source File the file in the share accessible to all the machines and in Destination %WINDIR%\Sun\Java\Deployment\deployment.properties

We create another file entry with the Action of Delete an the Destination of %USERPROFILE%\Sun\Java\Deployment\deployment.properties  this is to ensure that the Users copy does not go above the System Wide one since a user preference will override the systems.  This one we Create it under the User Configuration node

We now do one last entry under Folders so as to make sure the folder is created for the configuration file since if it is not the file is not copied.

Now that it is done we can close the edit window and attach the policy to the OU where the users we want to keep using Java but with higher security settings are, we do this by Right-Clicking on the OU we want to apply the policy against and choose to link an existing one

From the list we select the one we created

Once Linked next time the GPO refreshes the policy should apply and settings should be set. Do test in your own environment and adjust these steps as needed, remember one can use WMI Filters, and different standards may apply, this is just one of many ways for a certain scenario but still hope you find the information useful. For more information on the file format and details look at http://docs.oracle.com/javase/7/docs/technotes/guides/deployment/deployment-guide/properties.html

Update:

For those asking how it impacts the levels with the vulnerability trying to execute here are how the Medium, High and Very High security levels mitigate the vulnerability.

With Security Level at Medium

Should I say more?

With the Security Level at High

This would be the case if you have not set trust for the internal application you run and will require some user training and awareness chats since they can just hit run and the exploit will execute.

With the Security Level at Very High

One can go even further and have a network location or use the same method to specify trusted certificate lists and manage all the Certificate settings, for this you can take a look at http://docs.oracle.com/javase/7/docs/technotes/guides/deployment/deployment-guide/jcp.html#security

Another thing to keep in mind is to block access to the user to the Java Control Panel so as to prevent them from reducing the security levels. You will have to do this from a machine with Java installed so I recommend a Windows 7 or 8 Machine in the domain with the RSAT tools installed.

Set the Proper permissions for the user group you want to restrict, in the example I use the local Users group as an example, make sure your admin account is not under the group you decide to use since the most restrictive permission will apply first, here it is only as an example not the recommended setting since your environment will vary.

Make sure it is set to replace the permissions:

This settings will apply to a x64 system, make sure to also add a path for x86 system to then file or create a separate policy for those and use WMI Filters ass needed.

Now after the policy has been updated and user tries to to access the control panel shortcut to modify the settings he should get:

The file permissions can also be used to block users from creating and reading the %USERPROFILE%\AppData\LocalLow\Sun\Java\Deployment\deployment.properties  file on Windows Vista and higher versions of Windows and %USERPROFILE%\AppData\Sun\Java\Deployment\deployment.properties on Windows XP and 2003 systems.

Comments

[HandyAndy]

I beleive you have an extra s in the portion of the gpo that creates the folder I think it should be
%WINDIR%\Sun\Java\Deployment and not %WINDIRs%\Sun\Java\Deployment

[Aakash]

Excellent post! We have Java applets that are unfortunately not signed, but are needed for our users to do their job (these are very old programs). Have you found a method to whitelist specific sites using GP while still using the "Very High" security setting?

Thanks!

[Matt]

You may be better off deploying the file directly from the GPO directory:

Within the GPO:
Computer config\policies\windows settings\script\
Go into either Startup or Shutdown, click Show Files to obtain the path to the GPO files.

[Carlos Perez]

Thanks will fix the typo

[Carlos Perez]

Matt
In fact that is what I do in the next post, I use the SYSVOL share to move the files, in the production environment we also used it to house a trustedca file that gets pushed, it was a fight with devs since they did not want to create a single cert for internal use since it would break their "Internal Workflow"

[thomas]

really i get benefited from your post . you have explained clearly step by step and i expecting more details about other java version thank u