Lassi Lehto
Helsinki University of Technology
Telecommunications Software and Multimedia Laboratory
Lassi.Lehto@fgi.fi
The new category of Web content: dynamically loaded executable code run on client's local CPU, raises new security concerns in the Internet community. The Java language is currently the predominant form of the Web executable content. The Java platform contains several features designed to address the inherent security problems. The first implementation of the Java security was based on the Sandbox security model. The most important software modules enforcing this model are: Class Loader, Byte Code Verifier, and Security Manager. The Sandbox model has since been extended and some significant new security features are available in the Java Development Kit (JDK) version 1.1. These include: digital signatures, message digests, key management and access control lists. Despite the various security modules and the security features built into the language itself, several problems compromising Java security have been reported. The end user has two possible defences against the threats imposed by Java applets: keep informed and be cautious, or switch it off.
The communication networks are becoming ubiquitous. There are several reasons driving this development further on [17]. The early applications were concentrated on office environment; the goal of paperless office was commonplace. The wide acceptance of client/server computing model emphasized the need for wide-bandwidth networks. The telecommuting, accessing the office computing network from one's home computer using for example a dial up line, has gained popularity, along with other network-based collaborative working practices. The popularity of Internet, driven by the sudden upsurge of the Web platform, has brought network connections to the masses.
Serious security concerns have been raised by the immense expansion of the communication networks. As more people become connected to the global Internet, the probability of an intruder being among them increases. There is an evidence about the establishment of organized criminal groups devoted to exploiting the network vulnerabilities. Several common practices in the current Internet communication make it relatively easy to engage in dishonest activities. The major part of the millions of e-mail messages transmitted every day are sent as plain text, without any protection against eavesdropping. A remote login without password encryption is a prevalent habit. The emerging electronic commerce frequently involves sending credit card numbers unprotected. The new form of the Web content, software modules loaded automatically to the browser and executed locally, imposes a new threat to an unsuspecting Web surfer.
Java applets, the predominant form of the current Web executable content, introduce a novel category of security problems to the network computing. The dynamic downloading of an executable file from an unknown network source and the subsequent execution of the downloaded code on the local CPU increases significantly the risk involved in network-based computing. The local computing environment has traditionally been protected by the following rules:
Java applets evade all of these precautions. The high level of attention paid on the Java security issues is certainly warranted; there are about 40 million people surfing the Web with Java -enabled browsers [14].
A Java applet can be embedded into a Web page by a <APPLET> tag. The following piece of HTML code illustrates its use.
<APPLET code="SomeJavaCode.class"
width=300
height=300>
<PARAM name=input1 value="value1">
<PARAM name=input2 value="value2">
Your browser does not know how to exec Java applications.
</APPLET>
The plain text inside <APPLET>, </APPLET> tags is displayed only in the browsers that do not support Java. Parameters can be delivered to Java applet by name/value pairs in the <PARAM> tag. The loading and start up process of a Java applet is depicted in the Figure 1.
Figure 1. Loading and Start Up of a Java Applet.
An unsuspecting user browsing the Web is particularly exposed to attacks performed by applets, because an applet does not necessarily give any visual cue of its existence. Since the Java language supports multi-threaded execution of the program code, an applet can alternatively create an independent thread to do something nasty in the background, while the applet runs its cover show on the foreground. This kind of background thread can even be left running when the applet exits.
Being a complete high-level programming language, Java enables the creation of very sophisticated attack applets--if the security defences can be broken. Taking these new threats into the consideration, the designers of the Java platform included several security-related aspects to the system.
The initial security concept designed specifically for the Java applets is called the Sandbox security model [5]. The name comes from the fact that applets are restricted to act only inside their "sandbox", a safe playing area. The main goal of the Sandbox security model is to enable execution of an untrusted code in a safe and trusted environment. In the initial design of the Sandbox model every single piece of code loaded from the network was considered untrusted and placed to the sandbox; under strict limitations set by Java run time. The classes loaded from the local Java run time libraries or from the local disk are regarded as trusted. This security model thus only provides for rather rough security control: code is either considered trusted with full access to the local system, or untrusted with significantly restricted access. The new features introduced in Java Development Kit (JDK) version 1.1 (published in Feb 97) offer facilities for more detailed management of security policies.
Some strong arguments against the viability of the Java Sandbox security model have been expressed. The model is said to be too coarse: end-user can only choose between two extreme cases, both having their own drawbacks. A Java code is assumed to be safe and given complete access to the local computing platform or it is considered untrusted and its capabilities severely restricted and consequently the usability of the code significantly diminished. Even the basic concept of the Sandbox model has been questioned. According to this critique the Sandbox model concentrates on guarding the perimeter of the computing environment; once an attacker breaks through the defence line, the whole system is compromised [7]. The responsibility in ensuring the security of the Java platform has also been said to be too distributed. The Web browser, underlaying operating system, network software and Web server all play important role in the context of the security in the Java enabled Web environment.
A more thorough approach for Java security is clearly needed. This need has also been recognized at JavaSoft. A third party consultant has been hired to formulate a comprehensive security model for Java platform. As a result of this initiative a document "Security Reference Model for the JDK 1.0.2" [4] has been published. The paper is the first attempt to formally specify the Java Security Model. The overly simplistic and pragmatic design of the Sandbox model has been extended to explicitly define the parties involved in the overall security structure of the Web executable content. The components identified include:
The global security invariant is defined in a rather general level: "Downloaded applets are constrained by the application policy as configured by the client system administrator or end user". The reference model also determines the security transitions between the components during the process and the more detailed security invariants to be respected during the transitions. The document forms a basis for more formal analysis on the responsibilities of the various components acting in the complex processing environment of the Web executables.
A new more flexible security model, The Gateway security model, has been designed to be employed specially in the Java Electronic Commerce Framework, JavaSoft's general framework for Internet based financial applications [6]. The strict limitations set by the Sandbox security model effectively prevents actions needed in applications related to electronic commerce. There are only two categories of trust in the Sandbox security model: complete trust or complete untrust. The nature of applications executing business transactions calls for more fine-grained levels of confidence.
Electronic commerce typically involves several application programs, made by different vendors, communicating with each other and sharing common data resources. Varying levels of trust exist in the mutual relations between these applications. The Gateway security model introduces the concept role as an indicator of the position of a particular application in the actual transaction. This facilitates participating applications to trust each other for some purposes and not for others. In the Sandbox model the functions restricted by security policy include general system access processes, like reading or writing the local file system or making a network connection. The Gateway security model introduces more abstract concept of right. In the context of the Gateway security model a right is an abstract privilege, which can be used by a principal. Rights are implemented as objects and can also be delegated from one principal to an other. In electronic business transactions a diverse set of application-related rights is needed. Therefore in the Gateway security model each participating application can create rights.
The practical implementation of the Gateway security model follows ideas originally presented in the so called Capabilities model. The basic principle in the Capabilities model states that possession of an object authorizes the use of it. The object representing the abstract right to do something is called permit. A special service module called gate awards permits to individual software objects. The judgement whether the permit be granted or not is based on the role of the object. The role is authenticated by digital signature based on public-key cryptography. A simplified flowchart of the interactions in the authorization process is depicted in Figure 2.
Figure 2. The Gateway Security Model
The authentication by digital signatures forms the mechanism by which two companies, for instance a bank and a merchant offering online purchase facilities, can establish appropriate business roles needed in electronic commerce. The trust is based on the formal contract defining the rules for online transactions. This written contract signed by both parties enables Gateway security roles to be digitally signed and delivered.
The Java programming language has been advertised to be, besides many other positive adjectives, a safe language. The most important safety features of Java language are related to memory management. Java does not allow memory pointers to be constructed by the application code. For instance a Java application can not treat an integer as a pointer to a memory location. Java enforces strict rules for casting, thus eliminating inappropriate object references and making the language essentially type safe. Type safety involves each object reference to conform to the type system of the language. Arbitrary memory pointers and forged object references are the most often employed hacking techniques.
The reliable object reference enables multiple Java applications to be running in the same address space. Explicit visibility and access declarations (public, private, protected) effectively isolate applications from each other. Objects can be created only by the new -operator, which invokes object's constructor method. Access definitions in the constructor method strictly defines which modules are allowed to create a new object. This way an applet can be prevented from replacing critical security related objects creating new instances of them.
Memory management is taken care of by a dedicated Garbage Collector. Being a multi-threaded language, Java can take care of the garbage collection silently in the background. There are no explicit commands to allocate or de-allocate memory resources. This eliminates one of the most usual programming bugs making the Java applications more reliable and easy to maintain. Java run time checks the code for an array index overflows. This, together with the fact that pointer arithmetic is not allowed, prevents some common memory leakage problems.
The runtime environment, Java Virtual Machine (JVM), present in every Java-enabled Web-browser, contains three important components related to applet security: Byte Code Verifier, Class Loader and Security Manager (Figure 3).
Figure 3. Java Security-guard Modules
While browsing the net a user can come across an HTML -document containing a reference to a Java class -file. When the Web browser recognizes the <APPLET> tag indicating the Java reference, the browser delegates the further processing of the tag to the Java run time. The Class Loader module is responsible for requesting the class file from the Web server.
There are two different Class Loaders implemented in a Web browser: the Applet Class Loader responsible for loading class files over the network and the System Class Loader loading classes from the local resources. A separate name space is assigned to every applet loaded from the net (the applets loaded from the same directory on a specific server are grouped together into same name space). This way the Java runtime is able to maintain the trusted code in a dedicated name space, separated from the untrusted code. The class loader used to load the class is tagged to its name space. The Java runtime can thus always determine the source of a given class and restrict the activities of the class accordingly. The separate name spaces enables Java run time to prevent an applet from replacing some critical system class by a malicious code. For apparent reasons the applets are not allowed to create a Class Loader.
Some criticism has been expressed because of the fact that every Web browser has its own implementation of the Java run time. Also critical security modules, like Applet Class Loader, has an individual implementation in each Java-enabled platform. Sun only provides a generic Class Loader to be extended as seen appropriate by each developer. The lack of central co-ordination in the security related features of the Java platform has been regarded as a major vulnerability of the system.
The second step in enforcing the loaded applet to follow the strict security guidelines is accomplished by the Byte Code Verifier. In the compilation process the Java source code is transformed to a machine-independent byte code - a code quite similar to an assembly language. This byte code is stored in the class file and loaded to the Web browser by the Applet Class Loader. The task of the Byte Code Verifier is to check the loaded byte code ensuring that it follows the rules set by the Java specifications. Only if the code passes the Byte Code Verifier without problems will it be allowed to execute. Especially the Byte Code Verifier makes sure the loaded code does not forge pointers, violate access restrictions or access objects using incorrect type information. Although these restrictions are already enforced in the Java language itself, the check is really needed because some purposefully modified compiler could have been used to produce the byte code. Consequently, classes loaded from the local trusted source (JVM libraries or code in the CLASSPATH) are considered built-in classes and not subjected to the Byte Code Verifier.
The byte code design of the Java has also been criticized. Since the semantics of the byte code are completely different from the semantics of the source code, one can actually do more by byte code than what is possible in the source code level. This way a forged compiler can possibly produce byte code which evades some of the security restrictions enforced in the language level.
Not all security-related checks can be done in static mode. The role of the Security Manager is to supervise the untrusted code during the execution time. The Security Manager is an essential part of the Java run time implemented by the vendor of a Web browser. Each time the loaded code attempts to execute a critical task, the Java run time consults the Security Manager to determine whether the procedure is allowed to proceed or not. A decisive factor in this judgement is the class loader used to load the code. The most significant limits the Security Manager imposes to untrusted code include:
The Security Manager prevents applets from introducing an own Class Loader. The applets are also strictly forbidden to create a new Security Manager.
The same concerns expressed about the varying implementations of the Class Loader module applies also to the Security Manager. Every Java-enabled application typically contains a unique version of the Security Manager, made by subclassing the default implementation from Sun Microsystems. A flawed version of the Security Manager compromises the security of the whole application. Appletviewer, the viewer tool included in the Java Development Kit and HotJava, the extendable Web browser from Sun Microsystems, support configurable Security Manager, which behaviour can be tuned by presetting parameters in a configuration file. This approach also opens a possible security hole on an uninformed user's platform.
The latest Java Development Kit version 1.1, released in Feb 97, includes a special security related Application Programming Interface, Java Security API. The main components of this API are digital signatures, message digests, key management, and access control lists. The overall design of the Java Security API is based on the principle of algorithm- and implementation-independence. The API introduces a concept Cryptography Package Provider, an interface to security related functionality. A particular application employing security features can select an arbitrary existing solution, realized in software or in hardware, to provide the practical implementation. This approach enables also interoperability across different security packages.
The Java Security API, like many other similar software packages, encounters serious distribution problems due to US export control regulations. Since the export of strong cryptography is prohibited by law, Sun has made an announcement about the future release of a separate security package, Java Cryptography Extension (JCE), to the domestic market. This extension will include block and stream cipher, symmetric and asymmetric encryption, and support for multiple modes of operation and multiple encryption [8].
Digital signature is a fixed-size output generated from a digital file by a hash function and encrypted by signer's private key. The signature has the following properties:
Digital signatures are widely used to verify the source and correctness of a message received over the network. The Java Security API provides the general framework and tools needed to work with digital signatures, create and verify them, but leaves the selection of the specific algorithm and its implementation package to the Java developer. The JDK 1.1 version includes a default Cryptographic Package Provider with Digital Signature Algorithm (DSA, NIST FIPS 186).
To facilitate the digital signing of a Java applet, usually consisting of several separate files (class files, images, audio files etc.), a special archive format, Java Archive (JAR), has been designed. All the files making up a Java applet can be combined into one JAR file and then digitally signed. The new browsers released by Sun (appletviewer, HotJava) recognize signatures and treat applets accordingly, as preset by configuration parameters. If seen appropriate, a specific signed applet can this way be allowed out of the sandbox. The same functionality is expected in the next major release of the popular Web browsers, Netscape Navigator and Internet Explorer, to be released in the summer 1997.
In addition to programming API for digital signatures, the JDK 1.1 release also contains a command line tool, javakey, to manage the database containing security information and to digitally sign JAR files.
The JDK 1.1 release also provides functionality related to message digests. A message digest is a fixed-sized output, digest, from an arbitrary-sized input, typically a digital file containing some important data. The output is generated by a one-way hash algorithm. The digest has the following two properties:
Message digests are used as reliable and unique identifiers of received data. A message digest is sometimes called digital fingerprints of the data.
Like with digital signatures, the framework for message digests is algorithm- and implementation-independent. Java developers can introduce various algorithms and their implementations to the system as seen appropriate. The default Cryptographic Package Provider included in the JDK 1.1 release contains implementations of two message digest algorithms: MD5 (Message Digest algorithm MD5-RSA, RFC 1321) and SHA-1 (Secure Hash Algorithm, NIST FIPS 180-1).
A few APIs and tools for basic key management are provided in the JDK release 1.1. The system enables creation of identities, representatives of real world elements like individual persons, companies, software modules etc. Each identity has an associated key or key pair and may have one or more certificates. The support for a specific certificate format like X.509 v3 is not included in the JDK version 1.1 but will be supported in the next release. A special identity category, signer, has both public and private key available and can thus digitally sign data files. A concept identity scope serves as an abstract definition of identity repositories, like PGP key rings and other identity databases. Other functionalities provided include: the creation of new keys and the import of existing ones, the same procedures related to certificates, and the assignment of appropriate trust level to each identity. The are only two trust levels available in the JDK 1.1: trusted and untrusted, but later releases are promised to allow for more detailed categorization of trust levels.
The definition of the concept access control list (ACL) is introduced in JDK version 1.1. The new Security API contains a preliminary implementation of the definition. However, this implementation is not used internally by the other security modules and is guaranteed to undergo a substantial revision and extension in the next release. ACL is used to control access to the certain resources residing on a specific computer. Typically ACLs will be used on servers providing different kind of online services.
According to the ACL architecture defined in JDK 1.1, an ACL is a data structure consisting of a list of ACL entries. Each ACL entry contains a set of permissions associated with a principal. A principals is an object representing some real world subject, like an individual user or a group of users. A permission is related to a certain resource and can be either positive (granting access) or negative (denying access). The architecture also defines rules for calculating the access, based on a given combination of permissions.
Since the public release of the Java language in May 1995, a couple of security related deficiencies in the language and improper implementations in some Java-enabled applications, e.g. Web browsers, have been reported [2]. Most of the problems are not of serious nature, they mere enable rather annoying effects to be concealed into an innocent-looking applet. Because the most important application area for Java has so far been the Web executable content, realized by Java applets, the focus of Java security investigation has also concentrated on applets.
McGraw and Felten [13] classify the hostile Java applets into two basic categories: attack applets and malicious applets. Four possible threats imposed by Java applets can be identified:
An attack applet aims at system modification, the other three threats are attributed to malicious applets.
Being a full-fledged programming language, Java provides facilities to access system memory, other system processes, and the file system. Untrusted applets are carefully prevented from touching critical system resources by the Sandbox security model. Nevertheless, several flaws in the practical implementations of the Java run time have been reported. Some of these faults have been exploited in the laboratory to create attack applets gaining full access to the client system resources. There are no confirmed reports of attack applets in the real Web environment.
About ten different faults possibly enabling system modification have so far been reported. The reason for the flaw in most of the cases has been an improper implementation of a certain Java feature on a specific version of a Web browser. Practically all the flaws were immediately patched and promptly corrected in the next release. A few of the problems are discussed in the following.
The first widely published security problem is based on co-operation between an attack applet and a bogus DNS server delivering erroneous information. By this rather complicated arrangement the attack applet can breach the Sandbox security model and make a network connection to an arbitrary machine in the Web. The attack could be used to scan ports of another machine, located in the same local network as the client executing the applet; even if the network is behind a firewall (hence the name of the attack: Jumping the Firewall, Figure 4). The fault enabling this attack was a too permissive test comparing IP addresses in Netscape Navigator 2.0.
Figure 4. The Jumping the Firewall -attack
A second attack, firstly reported in Mar 1996 and again raised in the latest public announcement in Feb 1997, exploits the Java Sandbox feature that a code loaded from the local file system is considered trusted and given a full access to the system resources. The original flaw allowed the attacker to create a class name like: /programs.netscape.cache.file706. The Java run time would search for such a class from the location: /programs/netscape/cache/file706. An imaginary attack would involve making the browser to load a class file to the browser's cache directory and then requesting it again by a reference to the proper local path. On the second time the code is loaded from the local disc, regarded trusted and given full access to the client system. The flaw was to allow class names to start with a slash (hence the name: Slash and Burn, Figure 5). The latest revelation of a Java security problem is based on the same idea. In this scenario a file: URL is used to load a port-scanning code from the local browser cache. Because code is coming from the local machine it is granted an access to all local ports, according to Java Sandbox model. The flaw affected Microsoft Internet Explorer, which caches files with their original names. The company immediately released a patch to solve the problem.
Figure 5. The Slash and Burn -attack
The security problem prompting the widest press coverage so far was a bug in the Byte Code Verifier allowing an applet to create and install a Class Loader. The trick was to subclass the generic ClassLoader without calling the superclass constructor, which normally consults Security Manager to authorize the process. This flaw was found by Princeton SIP team and affected Netscape Navigator 2.01. By a properly constructed Class Loader the Princeton team was able to undermine the type safety of the Java language, thus gaining full access to the target client system (Figure 6).
Figure 6. The Applets running Wild -attack
In addition to assaults performed by attack applets accessing private system resources, some special types of invasion of privacy -attacks exist. Forging mail is one of them. A traditional way to forge mail is to connect directly to a sendmail server on port 25 and feed in the forged parameters about the sender. The mail forgery by an applet is even more effective, because in this case also the IP address of the real sender remains hidden. This kind of invasion of privacy -attack is possible using standard features of current Java environment and popular e-mail applications. The possibility to leave a thread running even when another Web page is loaded to the browser and the applet exited, enables another invasion of privacy -attack. This kind of thread could be used for instance to monitor user's Web surfing activities and report these back to the attacker, or even kill threads start up by other applets.
A denial of service -attack is present when the user's own access to the system is denied or seriously limited because of the actions performed by an applet. There are several different ways to totally consume a system resource - CPU cycles, main memory, display, even disc space - killing the browser or forcing the machine to reboot. One special case of the denial of service -attack is the possibility to kill execution threads of other applets running in the same CPU. This attack enables the creation of a business assassin applet aimed at harming some competitor in the industry. In most of the cases a denial of the service -attacks are mere annoyance. In the worst possible case some critical data may become corrupted or a certain important process be aborted.
The least serious group of malicious applets are those doing something annoying, like playing a sound file continuously or displaying unwanted graphics to the screen. This kind of applets are rather easy to develop and there are plenty of good examples available in the Web. (Some critical individuals have noted that actually all Java applets could be classified as annoying, because of their usual extended downloading time).
The deficiencies found so far in the Java security model and in its implementations don't seem to be really serious and most of the problems have been promptly fixed. Even though there are no confirmed report of any real computer security attack performed by a Java applet, a certain amount of caution is apparently warranted.
It is recommendable to gain a substantial amount of knowledge about security threats, risks and their available solutions before exposing one's local computing platform to the potential hazardous effects of the Web executable content. A sensible Web surfer should attain knowledge on several different areas to make intelligent decisions and to keep on the safe side.
A certain amount of knowledge about the Web sites one is surfing is always recommended. However, the global and dynamic nature of the Web makes it an unrealistic goal to only visit proven sites. Some experts suggest keeping Java disabled when surfing unknown servers [13]. Since the Java code loaded from local disc (from directories listed in CLASSPATH) is treated as trusted by the Java run time and thus isn't subjected to security restrictions, a special caution should be exercised when installing code to these directories. Since the Web surfing inherently exposes the client machine to a new category of risks, a self-evident precaution would be to avoid Web browsing on a machine containing some vital data or a mission-critical application.
One should also keep informed about the specific vulnerabilities related to a particular version of a Web browser, and always immediately install security patches as they become available. It is generally recommendable to always use the latest version of a browser.
There are some useful sites in the Web documenting the current security situation of the Java environment. These include:
Another good resource for Java security related news is the Usenet newsgroup comp.lang.java.security. Two Java security related vulnerabilities have prompted the CERT Coordination Center to issue an official alert. These can be found at CERT Web site [3].
The most radical defences against the possible Java threats include switching Java off in the browser or preventing Java code from entering the local network by stopping it right away at the firewall. The most popular Web browsers have a special switch available to enable or disable Java code execution. By default Java is usually enabled. There are several firewall products available, capable to screen off Java code [16]. This can be accomplished for instance by looking for an <APPLET> tag in the HTML -code, a .class -extension in the filename or a special magic number present in every Java binary.
There is also an example of a special security product, SurfinBoard by Finjan Software [1], designed to supervise Java applets while they execute in the browser and report on all suspicious activities. The product is also supposed to be able to prevent malicious applets from harming the system.
The Java byte code is an example of the Web executable content. This new category of Web data, downloaded dynamically and executed on the local CPU, increases the risk involved in being connected to the global Internet. The designers of the Java platform devised several security features to the language, destined to improve the reliability of the executable code and to diminish the chances for malignant exploitations.
A Java applet is effectively prevented from accessing the system resources of the client machine by special security modules: Class Loader, Byte Code Verifier and Security Manager. This security arrangement is called the Sandbox security model. New security features, introduced in the JDK release 1.1, include facilities to deal with digital signatures and message digests. Applet signing seems to offer a way to selectively allow applets out of the sandbox and grant them access to some indicated system resources.
There have been several reports on discoveries of certain deficiencies in the Java security features, usually on a specific implementation of the Java run time. These problems have only been exploited in the laboratory; there are no confirmed reports of Java -related security attacks in the connected global Internet. However, there are several examples of malicious applets available in the Web. These applets are intentionally designed to consume all system resources, effectively blocking the user from using the machine.
There are two basic defence strategies available against the increased
level of risk introduced by the Java executable code. The first defence
is built on an appropriate knowledge of the threats and a consequent caution
exercised while surfing the Web. A careful assessment of the risks involved,
weighted against the benefits offered by this new technology, is needed
for an intelligent decision about the guidelines to be followed regarding
Java usage. The diverse assortment of demonstrative malicious applets available
in the Web clearly indicates the existence of some dangerous uncharted
waters, possibly harmful for a Web surfer, on the Sea of Java. The second
approach is to make a rejecting decision about the issue and stop Java
code at the firewall. This solution arguably amounts to throwing the baby
out with the bath water.