Creating a corporate Java security policy

On January 23rd, 1996 something magical happened. Sun Microsystems released the Java Development Toolkit 1.0. From that moment on the 3 year old World Wide Web became more interactive. Browsers such as Mosaic and Netscape were able to show small applications inline which ran code on the client computer, allowing for instant feedback. At the risk of showing my age, I remember those early days of Java and I was quite impressed. Sun realized from the start that running code client side delivered over the web had severe security implications. The code was executed inside a sandbox with limited rights to access sensitive resources such as local disk drives and network sockets. Java code running stand alone, not using a webbrowser did not have these limitations. The sandbox model was secure (if you forget about the bugs in the implementation), but also very limiting for developers.  JDK 1.1 released in 1997 introduced a security model where an applet could ask for certain permissions. If the end user granted them, the code would execute, otherwise an exception would be thrown. The applet had to be signed with an X.509 certificate in order to provide the identity to be shown to the user. An example of an applet asking for local drive access is show below.

Note that this pop-up is very informative. It says that granting this privilege is a high risk (in bold). The applet could read, modify or even delete any of your files. Similar texts were shown for network access, etc. This is how I remember the Java applet sandbox security model. Applets can’t do much harm, if they would want to you will be shown a pop-up which will tell you what the risks are. Neat, clean, safe.

In 1998 Sun decided that this security model was too complex. With the release of JDK 1.2 (now renamed Java 2 Platform, Standard Edition or J2SE) the security model became more fine grained with the use of a security policy. This policy can be set to allow or disallow certain URLs, signers, etc specific privileges. This sounds great, but the default security policy that is shipped with Java/JDK/JRE ever since basically is a big on/off switch. If an applet needs additional privileges outside the sandbox, a single uniform pop-up is shown. No mention of high risk, or which privileges can be used by the applet. If the applet is signed by a Certificate Authority that your browser or OS trusts, it looks something like this:

if it was signed with a Certificate Authority that is not trusted it looks something like this:

In general I think end users always will make bad security decisions when it comes to browsing the web. However, the old style pop-ups would probably stop a lot more users from running suspicious applets. Think about it. Being able to operate outside of the Java sandbox gives applets full control over your computer. It can drop a malicious dll or exe on your hard drive, it can modify your registry to run it every time you log in, etc. And all you get as a warning is a lousy pop-up like the one above. Even ActiveX does that better these days. Of course I’m not the first to notice this. Many people have before. In 2002 a Mozilla bug report was opened requesting to change the misleading wording in the security warning, but no one has picked this up.

I think it is clear that the default Java security policy does not suffice today. End users cannot be expected to make the right decisions when pop-ups are shown. They certainly cannot be expected to write and maintain their own Java security policy. For home users, deinstalling Java is the best option right now. The chance you really need it to enjoy the web is quite low. If you do, at least take the precautions mentioned here. For corporate users, this problem is entirely different. Many organizations rely on software that use signed Java applets such as Oracle Forms. It is scary to think how many corporate desktops have Java installed and enabled in their browsers. Go ahead, try this signed applet example. Do you get a pop-up? Are you given a choice to run the applet? If so, your corporation is suspect to intruders, spamming your users with links to sites that show such a pop-up and use the Java applet to install malware. The Koobface worm is just one such example.

Fortunately there is something you can do about this: write your own java security policy. I’ll give a very short tutorial below, but I recommend reading the official Oracle documentation and this excellent site.

In the default java.home/lib/security/java.security file two Java policies are loaded:

policy.url.1=file:${java.home}/lib/security/java.policy
policy.url.2=file:${user.home}/.java.policy

You might want to remove the policy.url.2 to avoid users from changing your corporate Java policy. The default java.home/lib/security/java.policy is set up to restrict applets within the sandbox and ask the user what to do with signed applets. First, we need to turn off those pop-ups. You can do this by editing the java.home/lib/security/java.policy file or adding an additional one using policy.url.2 or policy.url.3 in the java.home/lib/security/java.security file. I recommend using a new file and placing it on a central file server. Add these lines:

grant {
permission java.lang.RuntimePermission “usePolicy”;
};

This tells the JVM to ignore the RSA signatures on all applets, and always and only use the Java policy defined by the policy URLs. Next, add any URLs with trusted applets that require access outside of the JVM sandbox. This acts like a whitelist:

grant codeBase “http://my.internal.site.local/-” {
java.security.AllPermission;
};

grant codeBase “http://another.site.local/-” {
java.security.AllPermission;
};

In the above the dash – is a recursive wildcard. Of course you can be much more granular instead of using java.security.AllPermission. The AllPermission property gives the same privileges a signed applet would get when the “Run” button was clicked on the pop-up.

Effectively you have now removed the choice of breaking out of the Java sandbox from the end user and defined it in a corporate java policy instead. This really is needed in any corporate environment with a JVM installed on the desktop. The default Java security policy is just a major security incident waiting to happen. In fact, abusing java applets is a well known technique in penetration testing. If the whitehats are catching on, you can count on the blackhats doing far worse.