10.5 Java applets

Java is an object-oriented, general-purpose programming language ^[16] that has a syntax similar to C++, dynamic binding, garbage collection, and a simple inheritance model [5]. The language was designed and developed by Sun Microsystems in the early 1990s. The original intent was to use the programming language in the world of consumer electronics. More specifically , it was assumed that it would become important in the future to have consumer electronics devices that could download software over a computer network, that this software had to be written in a specific programming language, and that Java would be an appropriate choice to do so. Instead of being compiled for a specific microprocessor, Java is designed to be compiled into a processor-independent bytecode and this bytecode is then interpreted in a Java virtual machine (JVM). This approach (i.e., the use of bytecode) would allow a manufacturer of consumer electronics to change the microprocessor(s) without losing compatibility with the existing software base.

After its initial release in the world of consumer electronics, it was recognized that Java ideally matched the requirements of a programming language for the emerging WWW. In fact, Java could be used to write a program that could be compiled into a platform-independent bytecode, and this bytecode could then be interpreted in a JVM. The JVM, in turn , could be embedded inside either the operating system or the browser. The second possibility was demonstrated in 1995, when Sun Microsystems released the first version of its Java-capable browser (i.e., HotJava) and Netscape Communications licensed Java to include a JVM in Netscape Navigator. A Java bytecode segment that is downloaded over a computer network and interpreted in a JVM on the browser is called a Java applet . Sometimes, it makes sense to compile the Java bytecode into the native machine code of the particular platform on which the JVM is running. In this case, a just-in-time (JIT) compiler is used.

The notion of software that can be dynamically downloaded over a computer network, if needed, gave birth to a new paradigm in the computer industry. The new paradigm was named network computing and most vendors launched press releases about the importance and future plans to support network computing and to build network computers (based on Java or any other network-capable programming language). Sometimes, network computers were also called thin clients and this term is still in use today. Meanwhile, network computing and network computers have disappeared, but the programming language that originally started the hype (i.e., Java) has remained and is likely to stay in the future.

It is commonly agreed today that Java is a programming language that has ˜ ˜good characteristics related to security and safety, meaning that Java programs typically contain fewer bugs and programming errors than programs written in other general-purpose programming languages, such as C or C++. This is because Java provides automatic memory management (including, for example, garbage collection), exception handling, and built-in bounds checking on all strings and arrays. Furthermore, Java doesn t have pointers, only has single inheritance, and is strongly typed. All of these features are important for a programming language that is used to write secure and safe code.

10.5.1 Security architecture

First of all, it is important to note that Java was not originally designed to be a secure and safe programming language. Instead, it was designed to be a programming language for consumer electronics devices, and it was assumed that Java programs would be downloaded from device manufacturers and approved content providers. But when Java was repositioned for the WWW, security immediately became a concern. By design, the Web allows any user to download anything from any site, whether it is from an approved content provider or not. If Web users can download and run a program by simply clicking on a hypertext link on a Web page, then there needs to be some mechanisms for protecting users and their computer systems against buggy , hostile , or malicious code. ^[17] Against this background, the developers of Java came up with a security architecture that includes a sandbox, a security manager, a bytecode verifier, and a class loader.

Sandbox: In the computer security literature, a runtime environment that is restricted and does not provide support for potentially dangerous things, such directly calling operating system functions or establishing network connections, is sometimes called a sandbox. Most browsers in use today provide sandboxes for the execution of Java applets. The first browsers implemented sandboxes that were very restrictive and didn t allow browsers to do useful things (e.g., reading or writing configuration files). In the recent past, however, software vendors have come up with browsers that allow Java applets to temporarily step out of their sandbox to provide more functionality under controlled circumstances. If, for example, a Java applet is digitally signed and originates from a trusted software developer, it may be authorized to step out of the sandbox and access the local file system or establish network connections to remote sites. This is where code signing technologies and systems come into play (refer to Section 5.3).

Security Manager: The sandbox of a browser is typically controlled by a security manager object (i.e., an instance of the SecurityManager class). Consequently, each browser may have a security manager of its own. ^[18] The security manager is called before any potentially dangerous operation is executed. It must determine whether the operation is allowed or not.

Class Loader: Because most of the security checks in the Java programming environment are written in the Java language itself, it s important to ensure that a malicious piece of code can t disable these checks. For example, one way to launch such an attack would be to have a malicious Java program disable the standard SecurityManager class or replace it with a more permissive version. Such an attack could be carried out by a downloaded piece of machine code or a Java applet that exploited a bug in the Java runtime system. To prevent these types of attack, the Java class loader examines classes to make sure that they do not violate the runtime system.

Bytecode Verifier: To further protect the Java runtime environment, Java employs a bytecode verifier. The verifier is to ensure that downloaded bytecode could only have been created by compiling a valid Java program. For example, it is supposed to assure that a downloaded program doesn t violate access restrictions or object types, and doesn t forge pointers. The bytecode verifier is implemented as a series of ad hoc checks.

The Java sandbox, security manager, bytecode verifier, and class loader are further addressed in [6] and many other references on Java security. They collectively implement a security policy.

10.5.2 Security policy

The Java security policy is complicated by the fact that the Java programming language is dual-use:

On the one hand, Java is a general-purpose programming language for creating any application software.
On the other hand, Java is also a programming language for creating applets that perform some particular tasks on the user s machine. Obviously, these different purposes require fundamentally different security policies. For example, Java s original implementers envisioned three different security policies that could be enforced by browsers:

Do not run Java programs at all.
Run Java programs with different privileges depending on their actual sources. For example, Java applets downloaded from remote Web sites would run with severe restrictions, whereas Java programs loaded off the local file system would be considered trustworthy and would have no such restrictions (they would have full access to all the system resources).
Run Java programs with no restrictions at all.

All three policies were implemented in Sun Microsystems HotJava browser, and the choice was left to the user. Most users chose the second policy. All browsers in use today allow the user to enable or disable Java, and to more severely restrict Java applets that are downloaded from remote sites than applets that are loaded from the local file system.

10.5.3 Code signing

The basic idea of code signing is that a software developer, publisher, or distributor digitally signs a software module, and that a user ”or a client software acting on behalf of the user ”verifies the digital signature before it actually executes the software module. The digital signature verifies the claimed source of the software module and the identity of the software developer, publisher, or distributor that is responsible and may be held accountable for its behavior accordingly . The use of digital signatures to verify the claimed source of software is conceptually similar to the use of shrink-wraps for physical software packages. Consequently, people sometimes use the term digital shrink-wrap to refer to them. In the introduction, we saw that BETSI provided a simple code signing system that worked that way. Since then, many vendors have developed code signing technologies and systems of their own. They all work similarly but use different terms. For example, Netscape Communications uses the term object signing system to refer to its code signing system, whereas Microsoft Corporation uses the term Authenticode . In fact, Authenticode describes a series of file formats for signing Microsoft 32-bit .exe, .cab, .dll, and .ocx files. ^[19] A digitally signed file contains the original unsigned file, the digital signature, and an X.509v3 digital certificate for the public key needed to verify the Authenticode signature.

Obviously, code signing technologies and systems can be used by browsers to have Java applets step out of their sandboxes under controlled circumstances. In fact, most code signing technologies and systems in use today allow users to dynamically assign specific sets of privileges to Java applets. The sets of privileges primarily depend on the trustworthiness of the corresponding software developers, publishers, or distributors. This basically means that not all software developers, publishers, and distributors are equally trustworthy and that there is some heuristic to determine and actually measure their trustworthiness. This heuristic must be provided by the user.

Code signing is an important building block of the security of browsers that support Java applets. As mentioned above, its implementation occurs in two phases:

In the first phase, code signing was implemented in a way that is conceptually similar to BETSI. The aim was to allow a user to determine and verify the claimed source of a Java applet. If the source was trustworthy, the applet would step out of the sandbox and have full access to the computer system and its local resources (similar to a Java application). If, however, the source was not trustworthy, the applet would still run in the sandbox. In this case, the trustworthiness of a software publisher was a binary decision (i.e., it was either trustworthy or not) and depended on the software publisher s certificate. This basically meant that the user could determine a set of certificates he or she was willing to accept and to consider as trustworthy. If a Java applet was digitally signed by a software publisher that had such as certificate, it was allowed to step out of the sandbox and fully access the computer system and its local resources. This phase was implemented in Microsoft Internet Explorer 3.0 and Netscape Navigator 4.0.
In the second phase, however, more granularity was added to the code signing systems employed for Java applets. More specifically, it was allowed that a Java applet could step out of the sandbox and access the computer system and its resources in some predefined way (i.e., the applet did not necessarily have full access to the computer system and its local resources). Giving applets capabilities in this way satisfies the ˜ ˜principle of least privilege, meaning that an applet can be given exactly the privileges it needs to perform its task, but nothing more. All major browsers support this phase in their latest releases. From a security point of view, this is advantageous and good news. Unfortunately, however, the configuration and proper use of a highly granular code signing system has also turned out to be difficult in practice.

All code signing systems in use today employ X.509v3 software publisher certificates ^[20] issued by (commercial or noncommercial) certification service providers such as, for example, VeriSign, Inc.

^[16] Similar attacks can also be mounted against e-mail user agents that support scripting languages.

^[17] The programming language was originally called Oak.

^[18] For example, a group of researchers at Princeton University found a number of security problems in the Java programming language in 1996. The team christened themselves the Secure Internet Programming (SIP) group and has published several bulletins informing users of the problems they found. Further information is available at http://www.cs.princeton.edu/sip.

^[19] In practice, however, most browsers have the same or very similar security managers.

^[20] Authenticode cannot be used to sign Windows .com files or 16-bit .exe files.