Applet Security

With the ever escalating popularity of the WWW has come the concept of downloadable, executable code embedded in Web Pages. The pace of the development of this paradigm has accelerated with the advent of the N.C. or Network Computer, which in theory will run almost solely code downloaded in this fashion. A number of languages have been developed suporting this system, including, for example, Sun's Java and Microsoft's ActiveX. However, despite its obvious advantages, executing downloaded code on a machine presents huge security risks. For this reason, many security measures must be implemented in any environment in which such code is encountered. In order to highlight the complexities involved in such a security system, we will make a detailed case study of probably the most popular language/runtime environment currently in use in this area, Sun's Java.

The Java language implements a number of measures to guarantee that both Applications and downloadable Applets are prevented from performing actions which could compromise security at a low-level on the host machine. These measures are implemented both at compile- and run-time.


Compile-Time Security

The basic goals of Java's in-built compiler security are to ensure:

These goals are achieved by enforcing certain language rules, which include the absence of pointers in Java and a strong typing mechanism, which disallows illegal casting and prevents ,for example, out-of-bounds array access, which could potentially gain access to unallocated memory and hence unauthorised information. Also, all memory allocated within a Java program is initialised on allocation to prevent access to information previously stored there.

As the compiler produces the executable bytecode, this should now be safe for execution on the host machine. However, there is the conceivable possibility of the construction of a malicious Java compiler, circumventing these security measures. To counter the possibility of such an attack, the Java run-time environment implements a number of checks on the bytecode before allowing execution.


Run-Time Security

When the bytecode is first presented to the run-time environment it is run through the Verifier, which checks to ensure that it does in fact adhere to the rules normally enforced by the compiler. Once the bytecode has been verified once, it need not be checked again, as the fact that it has passed successfully through the Verifier means that it cannot alter itself in any way.

The Classloader is then responsible for loading any necessary classes from the network. In doing this, it enforces strict naming conventions which ensure that classes with duplicate names are distinguished by their network source. These measures ensure, for example, that a spoof Security_Manager class cannot be downloaded, a situation which would cause grave security risks.

Only when these checks have been completed is the bytecode passed to the execution engine where it is executed without need for any further security checks, and so can execute at high speed.

These measures guarantee security of Java programs at a low-level, and are enforced on all Java code, including that developed or installed locally and so entirely trusted. It can be seen however, that these measures in themselves do not detract in any way from the functionality of the Java language. In fact, in many cases they help to prevent common programming errors inherent in languages such as C++, to which it bears a strong resemblance.


Applet-Specific Security

There are further restrictions which we need to enforce on downloaded applets which we do not need to apply to trusted local applications, eg. local file access and remote host connection. For this reason these higher level restrictions are enforced by the users Web Browser rather than by the Java language or environment itself. These restrictions are achieved by the browser's Security_Manager.


The Security Manager

The security manager in a browser is charged with dictating what access, if any, downloaded applets have to various resources on the host machine and to network connections. As browsers are supplied by different companies, different levels of security or 'paranoia levels' are enforced by different browsers. To illustrate this point, we will examine the restrictions imposed by two of the most popular browsers currently in use - Netscape 2.0/3.0 and JavaSoft's HotJava.


Netscape

Netscape's browser currently implements a very pessimistic Security Manager. Restrictions placed on Applets include:

While implementing such stringent restrictions does remove much of the potential power of the applet, it at least ensures that it is harmless.


HotJava

In HotJava, JavaSoft have made the level of security enforced user-configurable, thus allowing the individual user to decide what risk he/she is prepared to be exposed to, and hence providing the potential for more powerful applets. In order to regulate access to the local file system, Access Control Lists (ACLs) are used. If a user wishes to allow applets certain access permissions to a local file, he may add the file to the ACL, and specify these permissions. Any file not on the ACL is not visible to any applet.

As regards network permissions, the user can choose one of three security modes:

Currently under investigation at JavaSoft is a 'Firewall' mode. In this mode, the user can specify a firewall host boundary. Applets downloaded from within this boundary can connect to any URL, while applets from outside the firewall can only connect to URLs which are also outside.


The Future

So far we have seen the current security model in place to ensure that Applets can be downloaded and executed safely and confidently. As discussed, the Java language and run-time environment between them can implement what is theoretically a very safe security system. However, certain interested groups have have made successful attacks on the system in order to highlight its inadequacies. In light of these inadequacies, there have been calls for a low-level redesign of the Java language based on a formal security specification, something which does not exist for the current implementation. Because of this, a given implementation of the language cannot be verified. This is perhaps the most fundamental shortcoming of the language.

Irrespective of these issues, it is also true that the current security measures enforced by Web browsers restrict greatly the potential of downloaded code. This is a question that Javasoft are attempting to address with the release of JDK 1.1, which will support digital signatures & authentication. The support provided will allow a client to verify the source of a downloaded applet, and grant access to resources accordingly. ACLs will be supported so that different security measures can apply to applets from each individual source.

It is worth noting that this a similar approach to that of Microsoft's ActiveX which allows the creation of downloadable 'controls'. However, in the case of ActiveX, the model is much more simplistic. The source of a control is certified as trusted by a central certification agency. Certified controls are allowed full access to resources, while it is at the user's discretion whether to allow an uncertified control to execute. This model means that it is solely down to the certification agent to guarantee the security of the control. The risks inherent in this system have already been highlighted by the explode control. This was a control which succeeded in being fully certified but, when executed on any machine running Windows 95, performed a clean shut-down.

The Java approach however, is based on a key system which involves mutual recognition between sites. No central certification is necessary and access is granted purely on the basis of trust of the source, whose identity can be reliably detected. This system provides for 'shrink wrapping' of downloaded code, ie. we can trust code downloaded from Xsoft Ltd. to the same extent as that arriving from Xsoft Ltd. in a sealed package. It is clear that this system will allow for much greater functionality of Applets in future.

The JDK 1.1 Signed Applet Model