Chapter 3

Applet Security Restrictions

by Mark Wutka


CONTENTS

Applet Security

Applet security is generally regarded as a necessary pain by most Java programmers. The ability to download code on-the-fly is a major advantage, but it is also a wonderful tool for the same kind of people who like to write viruses that infect your PC. Fortunately, the designers of Java took that into account and developed a security model that protects your system from malicious attacks. You may consider some of the applet security restrictions draconian, but it is much better to have too much security than too little-especially when Java is still striving for acceptance. Theserestrictions do not apply to applications, because they are meant to access local files and the local network. The security restrictions are there to protect you from unknowingly loading a malicious program that can be hidden on a Web page. You have to manually run an application on your local system, however, so you are responsible if the application is malicious.

Security restrictions vary from browser to browser. Netscape, for instance, has a very tight security model, although HotJava allows you to switch off some of the security restrictions.

The Microsoft Internet Explorer version 3 (IE3) supports several security models from completely relaxed (no restrictions) to completely secure (won't download and run applets at all). In addition, IE3 allows digitally signed classes to have fewer restrictions.

Tip
Many browsers, including HotJava, IE3, and Netscape, relax the security policy for applets that are loaded from files on the local system-that is, files that are loaded with a type of "file:". If you load a file with "http:", even if the file is stored on your local drive, you will be under the full scrutiny of the security manager.

File Access Restrictions

File access is one of the most vulnerable places for malicious attacks. If someone were able to modify files on your system when you ran an applet, they could implant viruses on your system or just destroy data directly. For this reason, no applet is allowed to access the local filesystem in any way-not even in a read-only mode. After all, you wouldn't want someone implanting invisible applets on their Web page just so they could snoop your hard drive and copy files from it. You may be allowed to read and write files if your applet is loaded from the local filesystem using a URL of type "file:".

The inability to read and write files poses a major challenge for applet writers. For the moment, the only solution is to read and write files on applet's home Web server.

Network Restrictions

The network restrictions in Java may seem a little overboard, but they are there for good reason. The general philosophy of network security is that applets can only make network connections back to the Web server they were loaded from. An applet may not listen for incoming socket connections, nor can it listen for datagrams (connectionless network data) from anywhere but its home server. It also can only send datagrams back to its home server.

These security restrictions are intended to protect organizations that have Internet firewalls set up. In case you are unfamiliar with the intricacies of Internet security, many companies have large internal IP networks (the main networking protocol of the Internet). These networks are connected to the rest of the world through machines called "firewalls." A firewall's job in life is to protect the internal IP network from prying eyes in the outside world while allowing people on the inside to access data out on the Internet. These firewalls usually render the internal network invisible to the rest of the world. Given the clever ways people have found to attack systems, it is best to not give out any information about host names or addresses on the internal network.

The problem with Java is that applets run inside the firewall on your local machine. This means that without any network restrictions, your entire network is exposed to any malicious applets. You might be thinking that it would be nice if you could just tell your browser the names of hosts that you trust. It would not be difficult for the security system in Java to handle that, but it would keep your poor network administrator on a steady supply of indigestion medication, wondering when someone will trust an untrustworthy host. If you're an administrator at a site using HotJava, go ahead and get yourself a good spoonful of Maalox-you can completely turn off the networking restrictions in HotJava! Keep in mind, also, that Internet Explorer also lets you turn off all security restrictions. Netscape does not support such an option, however.

If your applet is loaded from the local filesystem, you can get around these security restrictions. You may have to set the appletviewer.security.mode system property to unrestricted to completely get around these restrictions. Because one of the other restrictions on applets is that they cannot change the system properties, you'll have to come up with unique ways of getting around this.

Other Security Restrictions

In addition to the file and network restrictions, most environments also place a few other interesting restrictions. They are discussed in this section.

Non-local applets may not access the system properties. A local applet may read and write the system properties. If an applet were able to change the system properties, any applet could change the appletviewer.security.mode property, for instance, and throw open a huge security hole. Other system properties contain information about the local machine, which could include the host name and IP address. If the machine is safe behind a firewall, you might not want this information getting out.

Non-local applets may not define their own class loaders. This is really an unfortunate restriction, because the ability to define new ways to add classes to the runtime system is one of Java's neatest features. The problem comes with the fact that when your class refers to another class, the system first goes to the class loader for your class to find the class you are referring to. If you wanted to create an applet that could read and write local files, you could create your own InputStream and OutputStream classes that did not consult the SecurityManager object for permission. When your applet is loaded via your custom class loader, the class loader will be asked if it can load the InputStream and OutputStream classes. A well-behaved loader would simply load the system versions of these classes, but an evil class loader will load the non-secure versions of these.

Applets may not call native methods. It would be terrible to have all these nice security measures built into Java, only to have an applet come along and bypass them completely by calling the native methods that are used by the system classes. For example, a malicious applet could call the native socket functions directly and snoop around the local network.

Applets cannot execute commands on the local system using the Runtime.exec method. Otherwise, a malicious applet could come along and execute commands to delete all your files.

Applets may not be able to define classes that belong to certain packages. Typically, they cannot define classes for the java and sun packages. Also, Netscape does not permit applets to define classes in the netscape package.

When a non-local applet opens a top-level frame (a window separate from the browser), the frame contains a warning message indicating that the applet is not trusted.

Getting Around Security Restrictions

This is a touchy subject because the Java security system is in place for good reason. Many companies would like to create Java applets that freely access other systems within the company's intranet, while denying such access to applets loaded from the Internet. Companies can do this if they load their intranet applications from local files. This is not acceptable in many cases, however. One of the advantages of downloading code is that software distribution is a snap. You just put the new copy of the program on your Web server. If you have to copy your intranet applets to each client, you are back in the old system administration nightmare.

Using Digital Signatures for Increased Access

The Microsoft Internet Explorer version 3 is the first major browser to implement digital signatures for applets. This digital signature mechanism allows you to permit applets from certain trusted sites to have more access to your local system. Internet Explorer's approach to digital signatures is basically an all-or-nothing approach. If an applet is digitally signed, it is considered to be a trusted applet and is allowed much more access, including the ability to write local files.

In order to take advantage of digital signatures for Internet Explorer, you need to pack-age your applets in Microsoft's cabinet format. Cabinets are discussed more fully in Chapter 14, "Creating Your Own Class Archive Files."

When you create your cabinet file, make sure you use the -s option to leave room for the digital signature. The following command packs all the .class files in the local directory into a cabinet called MyCab.cab and leaves 6,144 bytes at the beginning of the cabinet for the digital signature:

cabarc -s 6144 n MyCab.cab *.class

The tools for digitally signing your code are included with the Microsoft ActiveX SDK, available from http://www.microsoft.com/activex. The ActiveX development kit is free, and you can use the digital signature programs without any additional packages. If you want to develop ActiveX programs, however, you also need the Microsoft Windows SDK.

Note
To digitally sign your code for Internet Explorer you must have a Software Publishers Certificate, signed by a trusted certificate authority. You can find information on obtaining this certificate from Microsoft's Web server at http://www.microsoft.com/intdev/signcode.

Once you have created a cabinet file, use the SignCode program to digitally sign your code. If you simply type signcode on the command line, you will be presented with a handy step-by-step windowed interface for signing code. You can also use the command-line version of signcode. If your Software Publishers Certificate is in the file MyCert.spc and you want to use a private key called MyKey to sign MyCab.cab, you would use the following command:

signcode -name MyCab.cab -spc MyCert.spc -pvk MyKey

Once your cabinet is signed, any class loaded from that cabinet is trusted by Internet Explorer and is allowed free access to the local system.

Java 1.1 includes support for digitally signed Java classes. Under Sun's security policy, you are able to restrict access based on the signature. If a class is signed by Sun, you might permit it full access to your system. If the class is signed by a vendor that you do not completely trust, however, you might give it only limited abilities.

Because digital signatures are a part of Java 1.1, eventually all Java-enabled browsers will contain code to support digitally signed applets. These applets will be given much more freedom to access the local system. For now, however, if you really need to create applets that have little or no security restrictions, you have to create your own custom security manager.

Creating a Customized Security Manager

Creating a security manager is a difficult job, and any little error in programming can expose your system to attacks. Most security managers use the inClassLoader method to determine whether the current class was loaded by the AppletClassLoader class. If it was loaded by the applet class loader, it is subjected to the applet security restrictions. If you can legally get ahold of the source to an existing security manager, you should take a good look at it before attempting to create your own security manager.

Listing 3.1 shows a skeleton security manager. It performs no checks whatsoever, so you should use it only for your intranet applications-or better yet, just for testing.


Listing 3.1  Source code for AppletSecurity.java
// Uncomment one of these to create a security manager
// for the browser of your choice

// package Netscape.applet;     // for Netscape Navigator
// package sun.applet;          // for HotJava

import Java.io.FileDescriptor;
import Java.net.URL;

public class AppletSecurity extends SecurityManager
{
     public void checkAccept(String host, int port)
     {
     }

     public void checkAccess(Thread g)
     {
     }

     public void checkAccess(ThreadGroup g)
     {
     }

     public void checkConnect(String host, int port)
     {
     }

     public void checkConnect(String host, int port, Object context)
     {
     }

     public void checkCreateClassLoader()
     {
     }

     public void checkDelete(String file)
     {
     }

     public void checkExec(String cmd)
     {
     }

     public void checkExit(int status)
     {
     }

     public void checkLink(String lib)
     {
     }

     public void checkListen(int port)
     {
     }

     public void checkPackageAccess(String pkg)
     {
     }

     public void checkPackageDefinition(String pkg)
     {
     }

     public void checkPropertiesAccess()
     {
     }

     public void checkPropertyAccess(String key)
     {
     }

     public void checkRead(FileDescriptor fd)
     {
     }

     public void checkRead(String file)
     {
     }

     public void checkRead(String file, Object context)
     {
     }

     public boolean checkTopLevelWindow(Object window)
     {
          return true;
     }

     public void checkURLConnect(URL url)
     {
     }

     public void checkWrite(FileDescriptor fd)
     {
     }

     public void checkWrite(String file)
     {
     }
}

Once you have created your own custom security manager, you can install it over the existing security manager in the browser you are using. Netscape stores its classes either in moz2_x.zip (moz2_0.zip, moz2_01.zip, and so on) or moz3_x.zip, depending on whether it is Netscape 2.x or Netscape 3.x. HotJava stores its classes in classes.zip. Internet Explorer also stores its files in classes.zip, which is usually found in the C:\WINDOWS\JAVA\CLASSES directory.

You'll need a zip program to replace the old security manager. See the section "Creating Your Own Archive File with Info-ZIP" in Chapter 14, "Creating Your Own Class Archive Files," for more information on zip programs and creating Java class .zip files.

To install this security manager in a Netscape mozxxx.zip (moz2_0.zip, moz2_1.zip, and so on) file, perform the following steps:

  1. Go to the directory in which the mozxxx.zip file is stored.
    Under Win 95/NT, this is probably Program
    Files\Netscape\Navigator\Program\Java\classes.
  2. Create a subdirectory called Netscape, and then create a subdirectory under that called applet.
  3. Copy the AppletSecurity.class file you compiled into the Netscape/applet (or Netscape\applet) subdirectory.
  4. Make a backup copy of the mozxxx.zip file; you'll need it if you want to go back to the old security manager.
  5. zip -0 -u mozxxx.zip Netscape/applet/AppletSecurity.class

The procedure for HotJava is almost identical:

  1. Go to the directory in which the classes.zip file is stored.
    Under Win 95/NT, this is probably \hotJava\lib.
  2. Create a subdirectory called sun, and then create a subdirectory under that called applet.
  3. Copy the AppletSecurity.class file you compiled into the sun/applet (or sun\applet) subdirectory.
  4. Make a backup copy of the classes.zip file; you'll need it if you want to go back to the old security manager.
  5. zip -0 -u classes.zip sun/applet/AppletSecurity.class

The procedure for installing your own security manager for Internet Explorer is also very similar:

  1. Go to the directory in which the classes.zip file is stored. It should be C:\WINDOWS\JAVA\CLASSES, but may be slightly different if your Windows directory is in a different place. For instance, it might be C:\WINNT\JAVA\CLASSES.
  2. Create a subdirectory called com, and then create a subdirectory under that called ms. Under the com\ms directory, create another subdirectory called applet.
  3. Copy the AppletSecurity.class file you compiled into the com\ms\applet subdirectory.
  4. Make a backup copy of the classes.zip file; you'll need it if you want to go back to the old security manager.
  5. zip -0 -u classes.zip com/ms/applet/AppletSecurity.class

The next time you start your browser, your applets should be completely unrestricted.

Caution
Warning! Turning off applet security like this is extremely dangerous. Don't do this unless you know what you are doing. Remember, there is a better solution coming in the form of digital signatures, so only do this if you need unrestricted applets immediately.