While the Java Deployment Rule Set has been out for a short while now, I just got around to looking into it.

I initially had some doubts that I could get it to work how I intended, but after a short few hours, I had effectively disabled all java applications, except from the ones I explicitly had in my XML whitelist.

Backing up a little bit, everyone out there is aware that many enterprises have issues with upgrading to the latest java version. There have been many proposed solutions, some which work better than others, but in my opinion, there really hasn’t been anything that mitigates the risk significantly enough for the additional cost of any given solution. For example, using two browsers, one for internal use, one for web browsing, was a proposal I’ve heard thrown around. While this may work in theory, by doing this, an enterprise would incur more costs to keep the second browser patched and maintained, and more costs to build security controls around this new browser as well (policies to disable the ability for users to use a proxy, or using the intranet browser to go on the internet, ect), not to mention any additional installed software introduces additional risk just by being there.

In any case, after initially reading various articles, such as this one, this whitelisting concept sounded interesting, so I thought I would give it a try.

Preperation

First, to set up my VM, I installed the following applications:

1. JDK 7u40 (required)
2. JRE 6u30 (any old version of java should work)
3. OpenSSL for Windows (you’ll need a certificate to sign the JAR file)

After that, I mostly followed Oracle’s initial blog about Deployment Rule Sets, so some of the following is repeated, but I tried to give more detail, as some part’s were unclear in their blog if you just quickly wanted to throw together a POC.

Generate and Install Certificate

First, as you’ll need to sign the final JAR file, with OpenSSL installed, I ran the following commands to generate a PKCS12 file, answering the various questions as necessary:

cd C:\OpenSSL-Win64\bin

set OPENSSL_CONF=C:\OpenSSL-Win64\bin\openssl.cfg

openssl.exe req -x509 -nodes -days 365 -newkey rsa:2048 -keyout privateKey.key -out certificate.crt

openssl.exe pkcs12 -export -inkey privateKey.key -in certificate.crt -name jaxin -out server.p12

After everything was generated, I copied the various generated files to my desktop just to make things easy.

Next, I imported this certificate into Java by opening the Java Control Panel, going to the Security tab, and clicking on Manage Certificates.

From there, select the Signer CA drop down, and import the certificate you just generated.

Create and Install the RuleSet

Just for a simple test, I used the following ruleset and saved it to a file called ruleset.xml on my Desktop:

<ruleset version="1.0+">
  <rule>
    <id location="javatester.org" />
    <action permission="run" version="1.6.0_30" />
  </rule>
  <rule>
    <id />
    <action permission="block">
      <message>Blocked by corporate</message>
    </action>
  </rule>
</ruleset>

In the real-world, you would have a rule for every white-listed internal application at your enterprise, but I just wanted to test this new functionality out. The first rule should allow Java applets in the javatester.org domain to run fine, under version Java6u30. The second rule is a catch-all, and should block all other Java applets you browse to.

Now, in the command window, I ran the following:

jar -cvf DeploymentRuleSet.jar ruleset.xml

keytool -import -file certificate.crt -alias jaxin -keystore jaxin.jks

jarsigner -verbose -keystore server.p12 -storepass NA -storetype pkcs12 DeploymentRuleSet.jar jaxin


I then created the directory C:\Windows\Sun\Java\Deployment and copied the signed DeploymentRuleSet.jar file there.

Testing the RuleSet

Finally, the results 🙂

I navigated to http://javatester.org/version.html, and I was presented with the following (Note: I enabled the Java Console to always display, just to see what happens)

First, the Java 7 update 40 console appeared (left console appeared first), and appears to have checked the ‘whitelist’, and ran the applet under Java 6 update 30 (right console appeared second), just as the ruleset specified. The version the applet detected was in fact Java 6u30, which is what we were going for, as our “legacy” java software would break under the newer java versions 🙂

And, if we go anywhere else, whether it be intranet or internet, we are presented with the following:

So everything appears to work as intended.

Conclusion

While this was just a quick POC, it was enough to show this actually has some promise as a solution to mitigate the risk an enterprise incurs by using legacy java applications.

There are some cons to this approach:

• If not protected, the end user may be able to delete the DeploymentRuleSet.jar and bypass these restrictions. This mostly would affect corporations that allow their users to run as a local administrator, and so there’s less control over what the user does on their PC
• There would be some overhead of managing this DeploymentRuleSet.jar file, storing the certificates, ect.
• This is a new feature in Java, so there may be some bugs/vulnerabilities introduced (perhaps the white-list can be bypassed? I don’t know, I haven’t looked into how this feature works quite yet)

Still, I am thinking the benefits gained outweigh all the potential cons. Instead of flat out blocking java for the default rule, you can set the version to SECURE-1.7, which in theory will force users to have the latest/secure version of Java 1.7 installed in order to run all other Java applets they come across. While all versions of Java appear to be vulnerable to something, much of the risk of being infected would be mitigated by running the latest version of Java while browsing the internet.

So in conclusion, this (currently) appears to be a great risk-mitigation solution for enterprises who can’t (or don’t want to) remove or patch Java. I just hope that this white-list isn’t as easy to bypass as the JVM sandbox has been 😀