Stefanos Gritzalis

Department of Informatics, Technological Educational Institute (T.E.I.) of Athens

Ag.Spiridonos St., Aegaleo, GR-12243, GREECE

Tel: +30-1-5910.974, Fax: +30-1-5910.975, Email: sgritz@acm.org

Department of Information & Communication Systems, University of the Aegean

Research Unit, 30 Voulgaroktonou St., Athens GR-11472, GREECE

Tel: +30-1-6456.688, Fax: +30-1-6448.428, Email: sgritz@ru.aegean.gr

George Aggelis

Department of Informatics, Athens University of Economics and Business (AUEB)

76 Patission St., Athens GR-10434, GREECE
Email: gangel@hermes.aueb.gr

Diomidis Spinellis

Department of Information & Communication Systems, University of the Aegean

Research Unit, 30 Voulgaroktonou St., Athens GR-11472, GREECE

Tel: +30-1-6456.688, Fax: +30-1-6448.428, Email: dspin@aegean.gr

Abstract: Java is a system programming language having a number of advantages over traditional programming languages, due to the fact that it is a platform - independent language, thus promising truly network oriented computing as well as a nearly universal system for distributing applications. On the other hand, although being an interpreted, much simpler, scripting language, Safe-Tcl was proposed as an executable contents type of MIME and thus as the standard language for executable contents within email. Consequently, both languages claim to be suitable for transmitting executable content over the Internet, in other words providing mobile code. However, the ability to download, integrate, and execute code from a remote computer raises serious concerns about Java's as well as Safe-Tcl's effect on network security. In this paper, the details of each of the proposed security mechanisms are presented, as well as a comparison of the two security models, centered upon the efficiency and flexibility of current implementations as well as upcoming extensions.

1. INTRODUCTION

Java is a general-purpose class-based object-oriented language that has been developed and distributed by Sun Microsystems. Since its first release in February 1996 it has been experiencing a continuously growing interest due to an important capability provided by the Java platform, and not found in traditional programming languages. This ability allows Java programs written on one type of hardware or operating system to run unmodified on almost any other type of computer. However, security concern becomes especially important in such an environment, since the presence of downloaded executable content makes the local computer vulnerable to a potential attack from the possibly untrusted source of the executable. In recent versions, Java promises that through its new security mechanism it provides a secure environment for downloadable executable content that under specific circumstances can make use of a system's resources without compromising their availability and integrity [McGraw, 1996].

Safe-Tcl, a special purpose language, is based on Tcl, a procedural, high-level, scripting language designed to be simple, portable, easily embeddable and extensible. Safe-Tcl makes it possible for people to execute programs written in the Tcl language without knowing their origin or trustworthiness. It deals with potential security problems by restricting the behaviour of programs so that they have fewer capabilities than the users who invoked them. According to Tcl's designer J. Ousterhout, the proposed Safe-Tcl security model has two particular strengths: it separates untrusted code from trusted, with clear and simple boundaries between environments having different security properties, and provides mechanisms for implementing a variety of security policies.

Hostile applets are Web-embedded Java programs that may perform hostile activities against Web users, or Tcl scripts delivered via the context of email that manage to harm the destination hosting machine or application, while being executed there.

This paper addresses the security problems associated with Java and Safe-Tcl programming languages and provides some solutions for them. Section 2 provides a brief overview of the Java programming language focused particularly on the manner Java addresses downloadable executable content security issues. Section 3 on the other hand, describes the basic mechanisms of the Safe-Tcl security model. Current implementations as well as upcoming extensions of the two security models are compared in section 4, where their efficiency and flexibility are evaluated. Finally, in section 5 general remarks are discussed and in section 6 conclusions are presented.

2. JAVA LANGUAGE AND SECURITY
MODEL

One of the major design goals of Java is portability, which means that it is architecture neutral and consequently platform independent. More precisely, a Java program is portable not only in source code but also in compiled binary code. This is achieved through Java Virtual Machine (JVM), a system that simulates an imaginary virtual machine [Sun, 1997a], [Sun, 1997b].

Java's security model is focused on protecting users from hostile applets downloaded from untrusted sources across a network [Venners, 1997]. To accomplish this goal, Java provides a customisable sandbox in which Java programs run. Within its sandbox, the applet may do anything it wants but cannot gain access to the user's files, network connections or other resources.

Applets are loaded from the network by the applet ClassLoader which receives the bytecode instruction stream and converts it into internal data structures that represent the applet's classes. It then creates a namespace where it places the symbols of all the applet's classes. The Class Loader invokes the Bytecode Verifier before running a newly imported applet. The verifier subjects each applet class to a number of tests to prove that the applet will not be allowed to corrupt part of the security mechanism or to replace part of the system with its own code. The Security Manager is an abstract class that enforces the boundaries around the sandbox. Whenever an applet tries to perform an action which could corrupt the local machine or access information, the JVM first asks the security manager if this action can safely be performed.

The JDK is the official Java implementation from Sun. JDK1.2 includes a set of new features [Gong, 1997a], which introduce another modus operandi for the Java security system. The security policy introduced by JDK1.2 comprises of a mapping between properties of the running code (the URL of the code and the code signature) and a set of permissions granted to that code. If a piece of code carries more than one signatures then the permissions it is entitled to are computed as the sum of permission each signature is entitled to.

Permissions may no longer be granted in JDK1.2 to classes but to protection domains. The latter consist of all the objects that correspond to a principal who has been authorised by the system. Every class may belong to one domain only. It is possible to prevent the communication between different domains. When such a communication is necessary it may be performed either indirectly through system code, or directly if all the participating domains allow it.

Until JDK1.1, the code that performed access controls had to know the status of all its callers; these checks had to be performed by the programmer. JDK1.2 introduces a new class called AccessController which simplifies this process. A programmer may call the checkPermisssion method of this class, thus having the system itself perform the access control on behalf of the programmer.

The ClassLoader class has been replaced by the SecureClassloader. The latter can distinguish system classes from others and impose the designed security policy. In order to impose the security policy to locally installed applications, a new class has been introduced, called java.security.Main.

JDK1.2 and most of the emerging Java security frameworks applications depend on the existence of a Public Key Infrastructure (PKI). It is an obvious necessity for these frameworks to support the widely accepted standards for PKI and for the security mechanisms that surround them, such as X.509v3 certificates, SSL, and HTTPS.

3. THE SAFE-TCL LANGUAGE AND
SECURITY MODEL

Safe-Tcl was developed by M. T. Rose and N. Borenstein. It is based on J. Ousterhout's Tool Command Language (Tcl), which is a high-level interpreted scripting language.

The syntax of Safe-Tcl is identical to the syntax of Tcl [Borenstein, 1993]. Safe-Tcl is in fact an extended subset of Tcl, in that the "dangerous" primitives in Tcl have been removed, while certain new primitives presumed safe under all security policies have been added.

Like Java, this language is also safe with respect to memory usage (no C-style pointers, enforced bound checking in array references, storage managed automatically by Tcl interpreter). An interpreter consists of a set of Tcl commands, a set of variable values, and an execution stack, thus encapsulating completely the execution of a Tcl script. The facilities available to a Tcl script are determined by the set of commands defined in its interpreter.

Safe-Tcl also addresses security by controlling the execution of Tcl scripts by using a padded cell approach. According to this approach, applets (that is Tcl scripts, often called tclets) are executed in an isolated environment where their capabilities can be restricted in order to conform with the applied security properties. The isolation is achieved by using the dual-interpreter mechanism [Ousterhout, 1996].

According to this, two Tcl interpreters must be running at the local site in case of an application that wishes to execute an applet: the trusted interpreter and the unstrusted interpreter (the designations "Trusted" and "Untrusted" refer to the origin of the code being interpreted, rather than the interpreters themselves). Only trusted scripts such as those written by the user or the application may execute in the trusted interpreter, which retains full functionality. The untrusted interpreter is used for executing the applet, so all the commands that could result in endangering the system's security are made inaccessible.

The primary mechanism used by Safe-Tcl to provide restricted access to features that are essentially unsafe is command aliases. An alias is the association between a command in the untrusted interpreter and another command in a fully-trusted interpreter. Whenever the former command is invoked by a script in the untrusted interpreter, the latter is the one that is actually executed instead. To be more precise, the Tcl procedure that corresponds to the command in the trusted interpreter receives all the arguments from the command in the untrusted interpreter and, after being executed, its result is returned to the trusted interpreter as the result of the local command.

As mentioned before, all the commands that could result in endangering the system's security are made inaccessible to the untrusted interpreter. However, these commands are just hidden in some way, so as to make it impossible for the untrusted interpreter to invoke them. Having the capability to manage the entire set of those commands, the trusted interpreter may also invoke at any time the hidden commands of the untrusted interpreter. Doing so, it is able to use those commands in a restricted way, since they are invoked in the context of the untrusted interpreter and that is the place where their side effects will occur.

From the above description of the mechanisms used in Safe-Tcl stems one of the most important strengths of the security model that is proposed: Safe-Tcl does not prescribe any particular security policy, but rather provides mechanisms for implementing a variety of security policies. Since a security policy consists of the commands available in safe interpreters using the policy, it is possible to implement highly restrictive security policies for scripts of unknown origin, by providing no aliases at all in their interpreters.

4. EXTENSIONS AND
IMPLEMENTATIONS

4.1 Java

The JDK 1.1 includes a Java core API, built out of the java.security package that allows for digital signatures and message digests, key management, certificate management and access control. The Java Cryptography Architecture refers to the framework for accessing and developing cryptographic functionality for the Java platform and encompasses nearly the entire Java security API.

A concrete implementation of the Java security API is referred as a Cryptography Package Provider. JDK 1.1 comes with a default provider named SUN which includes an implementation of the NIST DSA algorithm, the MD5 and SHA message digest algorithms [Schneier, 1996]. JDK 1.1 provides a security tool, the javakey, whose primary use is to generate digital signatures for archive files (JAR files) which enable the packaging of class files. To sign an applet the producer first creates a JAR file and then creates a digital signature based on the contents of the JAR.

Since the ability to encrypt the data prior to being transferred is very important, APIs for data encryption are contained in a Java Cryptography Extension, as an add-on package to JDK.

Recently, new policy enforcement methods, secure code distribution and Java firewall blocking methods have been found and some of them implemented. These are briefly presented in the following paragraphs.

4.1.1 Policy enforcement methods

Once the code is authenticated to the system, that is associated with a principal, it is subject to the policy defined for that principal. To enforce this policy, three secure methods have been proposed [Wallach, 1997]:

• Capabilities,
• Extended stack introspection, and
• Name space management

Capabilities

Fundamentally, a capability is an unforgeable pointer to a controlled system resource. To use a capability, a program must have been first explicitly given that capability, either as part of its initialisation or as the result of calling another capability. Every top level class of an applet can be given by the system an array of capabilities (pointers to objects). Then the applet is able to use these capabilities whenever it wishes. The objects that are referenced by the capabilities may implement and enforce their own, internal security policy, by checking the parameters with which they are called. The Java runtime would have to be modified in order to make private all the methods which handle system resources directly or indirectly. It is only the capabilities themselves (the referenced objects) that should have access to these methods.

Capabilities are easy to implement in Java, because of the underlying infrastructure. Systems that support "capabilities" have been researched. One of these is the Java Electronic Commerce Framework [Goldstein, 1996], which provides a security platform, complementary to the one that Java is using right now, which is able to implement complex trust relationships between entities.

Extended stack introspection

The extended stack introspection is based on three primitives that must be implemented:

• enablePrivilege(target)
• disablePrivilege(target)
• checkPrivilege(target).

Every system resource must be associated with a target. Before the system allows the use of a system resource, it should perform a checkPrivilege on the specified target. When a thread, associated with a principal, asks for a system resource it should perform an enablePrivilege on the specified target. The security policy will then decide whether that principal is entitled to use this target and the system will or will not grant the privilege to the code. After the thread has finished using this system resource it must execute a disablePrivilege. The checkPrivilege primitive should check the stack and judge whether a privilege must be given or not based on the least privilege rule, in order to prevent trusted code from calling untrusted code and passing the latter the privileges of the former.

Name space management

Name space management is a method to enforce a security policy by replacing or hiding the classes that are visible by a program. There has to be a mapping between the applets (and their respective signers) and the namespaces that each applet will be able to see. Hiding a class from the namespace means that the applet may not be able at all to use it, while replacing the class with another (possibly a subclass of the latter) provides a means for controlling even more the way that the applet will call and use the methods contained in the aforementioned class.

4.1.2 Secure Code Distribution

Secure code distribution [Zhang, 1997] is one of the security issues that concern the Java community. There are various approaches to authentication for secure code distribution. One of them is the signed applets. The Java class file format is extensible. It is possible to add new attributes to it, without influencing the current structure or workflow of the classloaders. These new attributes can contain signatures for the applet which can be verified, provided that the user possesses the certificate of the entity who signed the applet. After the verification the security manager may grant certain rights to the applet, depending on the trustworthiness of the author or the person who has signed the applet. The level of trust, and therefore the level and types of rights that should be granted to the applet, that each user specifies for each applet author or signer can be defined a priori by forming a local security policy, accessible from the user through the browser and protected by all means available (e.g. filesystem rights) to the OS. Secure code distribution is already supported by Javasoft's JAR specification. The signature can be verified by the JDK infrastructure, providing a secure authentication means for the distribution of applets.

4.1.3 Confining the use of Java in a
network domain

An organisation may wish to ban all Java incoming traffic from the Internet, but wish to deploy and use Java applets internally, in its own domain. This may be achieved by blocking the Java applets at the firewall [Martin, 1997].

The first strategy in blocking Java applets at the firewall should be the rewriting of the <applet> tag by a proxy, wherever this is found. It could be in an HTTP transmission, or in mail or news messages (HTML enabled mail and news clients are common). Rewriting the <applet> tag will cause the client to ignore the existence of the Java applet in the message. It should be mentioned though that Javascript may be used in order to create the <applet> tag just before the page is viewed in the browser, rendering the above blocking useless. Another strategy that must be implemented is the blocking of the CAFEBABE signature. Every Java class file begins with this 4-byte signature [Sun, 1997b], so it is possible to block all Java classes as soon as they reach the proxy. In addition, another strategy that has to be implemented is to set the proxy to reject all files which have an extension ".class". However, if classes arrive at the firewall archived (JAR, Zip) the ".class" extension would not be detected.

If one decides to implement the aforementioned strategies, s/he should take under consideration the possibility of accidentally blocking useful information, e.g. files whose first 4-byte signature is CAFEBABE but are not Java classes, or files that contain the "<applet>" string but do not call any Java applets or even blocking files that end in ".class" but do not consist of Java classes.

The Princeton Group has released a product called JavaFilter [Balfanz, 1997] which may be used in a complementary way, when trying to block all Java traffic from specific hosts. JavaFilter is available for Microsoft Internet Explorer and Netscape Navigator for Windows and replaces the browser's classloader with a modified version of theirs. This tool provides the ability to the end-user to accept or deny the execution of applets from specific URL. In the case of a trusted code source, a classloader is initialised and loads the applet, while in the case of an untrusted one no classloader is initialised, preventing thus even the loading of the "untrusted source" applets. If an applet attempts to download itself from a URL not specified as a trusted or untrusted, then the JavaFilter asks the user whether s/he wishes to accept this code source as a trusted one. This user acceptance may be stored in the JavaFilter database; the JavaFilter performs automatic lookups to that database each time an applet attempts to download itself to the user's browser.

4.2 Safe-Tcl

Safe-Tcl has been available in the Tcl releases since the Tcl 7.5 release in April 1996. Safe-Tcl integration with Tk (a window system toolkit for building graphical user interfaces) is implemented as part of a Tcl/Tk plugin module for Netscape Navigator, which was released in July 1996. The plugin allows Web pages to contain Tcl/Tk scripts, and uses the Safe-Tcl mechanism to ensure that even untrusted scripts can be safely executed. Safe-Tcl supports safe interpreters and aliases but allows only a single security policy consisting entirely of builtin commands.

Future releases are intended to include standard authentication and encryption mechanisms to provide more control over the execution of scripts, as well as mechanisms to prevent denial-of-service attacks. These plans are described in the following paragraphs.

4.2.1 Authentication

If the source of an applet is unknown, the receiving application must assume the worst and restrict actions that the applet may take. However, if the application can deduce something about the author of an applet, then it may be able to grant more privileges to the applet. In other words, if the application can determine that an applet is one of the approved ones, it can make additional security policies available to the applet. There exist a variety of authentication mechanisms for verifying the origin of a mobile code segment, most of which involve encryption of some sort.

Authentication mechanisms can be used to distribute new security policies. For example, an untrusted applet may carry an encrypted trusted security policy with it, so that when an application executes the applet, it can safely load the security policy even though it doesn't trust the applet. In that way, authentication makes it possible for a variety of applets and applications to take advantage of new policies developed and distributed by experts.

4.2.2 Denial-of-service attacks

Safe-Tcl mechanisms can also be used to prevent denial-of-service attacks. More precisely, aliases can be created and used instead of commands that are associated with system resources and particularly with graphical user interfaces. The basic idea is to handle many such attacks, with a kill key that the user can press at any time to destroy the applet. With this approach an application need not worry about many denial-of-service attacks, since as soon as they occur the user will notice and kill the offending applet.

However, in order to prevent denial-of-service attacks in non-interactive applications, where the user is not able to notice the attack, a familiar operating-systems mechanism has been proposed: mechanisms to monitor CPU usage in Safe-Tcl will be implemented. Safe-Tcl's approach to CPU controls is to invoke a scheduling function in the trusted interpreter once the untrusted interpreter has executed a predefined number of commands, which can abort the applet. For interactive applets the scheduling function can check to see if the kill key has been pressed, whereas for non-interactive applets the scheduling function can implement an upper limit on CPU usage, as well as on memory allocation.

5. DISCUSSION

Both the languages described above make it possible to create environments where applets with different levels of trustworthiness can be executed with an acceptable level of risk, and that is the reason for them appearing to have an edge over other programming languages for mobile code, in terms of security.

One may claim that as far as security is concerned, Java work has concentrated on providing low-level security in a preferment manner, as opposed to Safe-Tcl which has focused on the higher-level aspects of security, but only in the specialised context of email. Moreover, it is claimed by those who vote for Java that the security model it offers is more complete than the one proposed by Safe-Tcl, since mechanisms like namespace protection and bytecode compilation go a long way towards safety and efficiency [Weiss, 1996].

On the other hand Safe-Tcl has some advantages over Java that simplify the creation of safe environments. The first is simplicity of the proposed model. It may be considered as just a generalisation of the user- space / kernel-space model that has been used successfully in operating systems for several decades [Gritzalis, 1991]. The second is that data and code are grouped together with similar security properties, which reduces the amount of code that must be aware of security issues. Finally, security policies are separated into well-defined modules that do not depend neither on host applications nor on untrusted applets, making it easier to analyse the properties of a security policy, and to reuse policies.

6. CONCLUSIONS

Currently the Sunscript group is working on Tcl-Java integration, since Tcl has several properties that complement Java nicely. Two new products were recently released named Jacl and Tcl Blend [Sun, 1997c]. The first is a new Java implementation of Tcl 8.0, that can be used to write extensions for Tcl in Java code that will provide cross-platform portability across UNIX, Windows and the Macintosh. The second is a new package for Tcl 8.0 that allows loading and interacting with the Java virtual machine. This kind of integration will probably guide to a security integration, since both languages have a built-in security model, the combination of which may be used to have more complete and flexible control over mobile code.

REFERENCES

[Balfanz, 1997] D.Balfanz, E.W.Felten, (1997) A JavaFilter, online http://www.princeton.cs.edu/sip

[Borenstein, 1993] Borenstein N, Rose M.T., (1993) MIME Extensions for Mail-Enabled Applications: application/Safe-Tcl and multipart/enabled-mail

[Goldstein, 1996] Goldstein T., (1996) The Gateway Security Model in the Java Electronic Commerce Framework, JavaSoft, online http://www.javasoft.com/products/commerce/jectf_gateway.ps

[Gong, 1997a] L.Gong, M.Mueller, H. Prafullchandra, R.Schemers, (1997) Going Beyond the Sandbox: An Overview of the New Security Architecture in the Java Development Kit 1.2, Proceedings of the USENIX Symposium on Internet Technologies.

[Gritzalis, 1991] Gritzalis D., (1991) Information Systems Security, GCS Publications (in Greek).

[Martin, 1997] Martin D., Rajagopalan S., Rubin A., (1997) Blocking Java Applets at the Firewall, Proceedings of the SNDSS 1997 Symposium on Network and Distributed System Security, pp.123-133, IEEE Computer Society Press.

[McGraw, 1996] McGraw G., Felten E., (1996) Java Security Hostile Applets, Holes and Antidotes, J. Wiley & Sons Inc.

[Ousterhout, 1996] Ousterhout J.K., (1996) The Safe-Tcl Security Model.

[Schneier, 1996] Schneier B., Applied Cryptography, J.Wiley & Sons.

[Sun, 1997a] Sun Microsystems, (1997) Secure Computing with Java: Now and the Future, at http://java.sun.com/marketing/collateral/

security.htm

[Sun, 1997b] The Java Virtual Machine Specification, (1997) online http://java.sun.com/docs/books/vmspec/

[Sun, 1997c] Jacl and Tcl Blend, (1997) online http://sunscript.sun.com/java/

[Venners, 1997] Venners B., (1997) Java's security architecture, online http://www.javaworld.com/javaworld/jw-08-1997/jw-08-hood.html

[Wallach, 1997] D.S.Wallach, D.Balfanz, D.Dean, E.W.Felten, (1997) Extensible Security Architectures for Java, Proceedings of the 16th Symposium on Operating Systems Principles.

[Weiss, 1996] Weiss M., Johnson A., Kiniry J., (1996) Security Features of Java and HotJava.

[Yellin, 1995] Yellin F., (1995) Low Level Security in Java, online http: //java.sun.com/sfaq/verifier.html

[Zhang, 1997] X.N.Zhang, Secure Code Distribution, (1997) IEEE Computer, June 1997, pp.76-79.