Low Level Security in Java

Abstract

The Java(tm) language allows Java-compatible Web browsers to download code fragments dynamically and then to execute those code fragments locally. However, users must be wary of executing any code that comes from untrusted sources or that passes through an insecure network.

This paper presents the details of the lowest-levels of the Java security mechanism. Before any downloaded code is executed, it is scanned and verified to ensure that it conforms to the specifications of the virtual machine.

Keywords

WWW; Java; HotJava; Security; Remote execution;

Introduction to the Java Language

The language was created for developing programs in a heterogenous network-wide environment. Since one of the initial goals of the language was to be used in embedded systems with a minimum amount of memory, the Java language is designed to be small and to use a small amount of hardware resources.

The Java compiler generates class files, which have an architecturally neutral, binary intermediate format. Embedded in the class file are bytecodes, which are implementations for each of the class's methods, written in the instruction set of a virtual machine. The class file format has no dependencies on byte-ordering, pointer size, or underlying operating system.

The bytecodes are executed by means of a runtime system, an emulator for the virtual machine's instruction set. The same bytecodes can be run on any platform.

Security

• Damage hardware, software, or information on the host machine.
• Pass unauthorized information to anyone.
• Cause the host machine to become unusable through resource depletion.

The lowest levels of the Java interpreter implement security in several ways.

Security though being published.

Security through being well-defined.

• All primitive types in the language are guaranteed to be a specific size.
• All operations are defined to be performed in a specified order.

Security through lack of pointer arithmetic.

Security through garbage collection.

• Failing to free memory once it is no longer needed.
• Accidentally freeing the same piece of memory twice.

Security through strict Compile-Time Checking.

• Objects cannot be cast to a subclass without an explicit runtime check.
• All references to methods and variables are checked to make sure that the objects are of the appropriate type. In addition, the compiler checks that "security barriers" (e.g., referencing a private variable or method from another class) are not violated.
• Integers cannot be converted into objects. Objects cannot be converted into integers.

Class File Verification

An additional problem with compile-time checking is version skew. A user may have successfully compiled a class, say PurchaseStockOptions to be a subclass of TradingClass. But the definition of TradingClass might have changed since the time the class was compiled: methods might have disappeared or changed arguments; variables might have changed types or changed from dynamic (per object) to static (per class). The visibility of a method or variable may have changed from public to private.

All class files brought in from "the outside" are subjected to a verifier. This verifier ensures that the class file has the correct format. The bytecodes are verified using a simple theorem prover which establishes a set of "structural constraints" on the bytecodes.

The bytecode verifier also enhances the performance of the interpreter. Runtime checks that would otherwise have to be performed for each interpreted instruction can be eliminated. Rather, the interpreter can assume that these checks have already been performed. Though each individual check may be inexpensive, several machine instructions for the execution of each bytecode instruction are eliminated.

For example, the interpreter already knows that the code will adhere to the following constraints:

• There are no stack overflows or underflows.
• All register accesses and stores are valid.
• The parameters to all bytecode instructions are correct.
• There is no illegal data conversion.

The verifier is extremely conservative. It will refuse to certify some class files that a more sophisticated theorem prover might certify.

Other languages can be compiled into the class format. The bytecode verifier, by not being specifically tied to the Java language, allows users to import code from outside their firewall with confidence.

The Class File Format

The Basic Format

A class file contains:

• A magic constant
• Major and minor version information
• The "constant pool"
• Information about this class (name, superclass, etc.)
• Information about each of the fields and methods in this class
• Debugging information.

• A Unicode [6] string
• A class or interface name
• A reference to a field or method
• A numeric value
• A constant String value

For each field and method in the class, the bytes in the class file indicate the field or method's name and its type. The type of a field or method is indicated by a string called its signature. Fields may have an additional attribute giving the field's initial value. Methods may have an additional attribute giving the code for performing that method.

Methods may, in fact, have multiple code attributes. The attribute CODE indicates bytecode to be run through the interpreter. Methods might also have attributes such as SPARC-CODE or 386-CODE which are machine-code implementations of the method. The HotJava browser will ignore the machine-code implementation of any method from an untrustworthy source, since it cannot verify that machine code is structurally sound.

The current implementation of the HotJava browser believes that any class file that comes from the network is untrustworthy. It will only run machine code that has been loaded from local class files. However, the class format can allow authors to digitally sign class files. Future browsers may be more trusting of signed machine code coming from trusted sources.

The Bytecodes and the Virtual Machine

• The maximum stack space needed by the method.
• The maximum number of registers used by the method.
• The actual code for executing the method. These bytecodes are for the Java virtual machine.
• A table of exception handlers. Each entry in the table gives a start and end offset into the bytecodes, an exception type, and the offset of a handler for the exception. The entry indicates that if an exception of the indicated type occurs within the code indicated by the starting and ending offset, a handler for the exception will be found at the given handler offset.

• 32-bit integer ("integers")
• 64-bit integers ("longs" or "long integers")
• 32-bit floating-point numbers ("single floats")
• 64-bit floating-point numbers ("double floats")
• pointers to objects and arrays ("handles")
• pointers to the virtual machine code ("return addresses")

Each method activation has a separate expression-evaluation stack and set of local registers. Each register and each stack location must be able to hold an integer, a single float, a handle, or a return address. Longs and double floats must fit into two consecutive stack locations or two consecutive registers. The virtual-machine instructions ("opcodes") will address longs and double floats in registers using the index of the lower-numbered register.

Objects on the stack and in registers are not (necessarily) tagged. The virtual-machine instruction set provides opcodes to operate on different primitive data types. For example, ineg, fneg, lneg, and dneg each negate the top item on the stack, but they assume that the top item on the stack is an integer, a single float, a long, or a double float, respectively.

The bytecode instructions can be divided into several categories:

• Pushing constants onto the stack
• Accessing and modifying the value of a register
• Accessing arrays
• Stack manipulation (e.g., swap, dup, pop)
• Arithmetic, logical, and conversion instructions
• Control transfer
• Function return
• Manipulating object fields
• Method invocation
• Object creation
• Type casting

The Verification Process

Pass 1

This pass ensures that the class file has the format of a class file. The first several bytes must contain the right magic number. All recognized attributes need to be the proper length. The class file must not be truncated or have extra bytes at the end. The constant pool must not contain any unrecognized information.

Pass 2.

• Ensuring that final classes are not subclassed, and that final methods are not overridden.
• Checking that every class (except Object) must have a superclass.
• Ensuring that the constant pool satisfies certain constraints. For example, class references in the constant pool must contain a field that points to a unicode string reference in the constant pool.
• Checking that all field references and method references in the constant pool must have legal names, legal classes, and a legal type signature.

Pass 3

• The stack is always the same size and contains the same types of objects.
• No register is accessed unless it is known to contain a value of the appropriate type.
• Methods are called with the appropriate arguments.
• Fields are modified with values of the appropriate type.
• All opcodes have appropriate type arguments on the stack and in the registers.

Pass 4

For example, if a method contains a call to another method that returns an object of type foobarType, and that object is then immediately assigned to a field of the same type, the verifier doesn't bother to check if the type foobarType exists. However, if it is assigned to a field of the type anotherType, the definitions of both foobarType and anotherType must be loaded in to assure that foobarType is a subclass of anotherType.

The first time an instruction that references a class is executed, the verifier does the following:

• Loads in the definition of the class if it has not already been loaded.
• Verifies that the currently executing class is allowed to reference the given class.

• Ensures that the method or field exists in the given class.
• Checks that the method or field has the indicated signature.
• Checks that the currently executing method has access to the given method or field.

After the verification has been performed, the instruction in the bytecode stream is replaced with an alternative form of the instruction. For example, the opcode new is replaced with new_quick. This alternative instruction indicates that the verification needed by this instruction has taken place, and need not be performed again. It is illegal for these _quick instructions to appear in Pass 3.

The Bytecode Verifier

[Some extra information is kept about each instruction in a finally clause. This information is discussed further in the section Try / Finally].

Next, a data-flow analyzer is initialized. For the first instruction, the lower-numbered registers contain the types indicated by the method's type signature; the stack is empty. All other registers contain an illegal value. For all other instructions, indicate that this instruction has not yet been visited; there is yet no information on its stack or registers.

Finally, the data-flow analyzer is run. For each instruction, there is a "changed" bit indicating whether this instruction needs to be looked at. Initially, the "changed" bit is set only for the first instruction. The data-flow analyzer executes the following loop:

1. Find a virtual machine instruction whose "changed" bit is set. If no instruction remains whose "changed" bit is set, the method has successfully been verified. Turn off that "changed" bit.
2. Emulate the effect of this instruction on the stack and registers:
   • If the instruction uses values from the stack, ensure that there are sufficient elements on the stack and that the top element(s) of the stack are of the appropriate type. Otherwise, fail.
   • If the instruction uses a register, ensure that the specified register contains a value of the appropriate type. Otherwise, fail.
   • If the instruction pushes values onto the stack, add the indicated types to the top of the stack. Ensure that there is sufficient room on the stack for the new element(s).
   • If the instruction modifies a register, indicate that the register now contains the new type.
3. Determine the virtual-machine instructions that can follow this one. Successor instructions can be one of the following:
   1. The next instruction, if the current instruction isn't an unconditional goto, a return, or a throw. Fail if we can "fall off" the last instruction.
   2. The target of a conditional or unconditional branch.
   3. All exception handlers for this instruction.
4. Merge the state of the stack and registers at the end of the current instruction into each of the successor instructions. In the exception-handler case (2c), change the stack so that it contains a single object of the exception type indicated by the exception handler information.
   • If this is the first time the successor instruction has been visited, indicate that the stack and registers values calculated in Step 2 and Step 3 are the state of the stack and registers prior to executing the successor instruction; set the "changed" bit for the successor instruction.
   • If the instruction has been seen before, merge the stack and register values calculated in Step 2 and Step 3 into the values already there; set the "change" bit if there is any modification.
5. Go to Step 1.

To merge two register states, compare each register. If the two types aren't identical, then unless both contain handles, indicate that the register contains an unknown (and unusable) value. For differing handle types, the merged state contains the common ancestor of the two types.

If the data-flow analyzer runs on the method without reporting any failures, then the method has been successfully verified by Pass 3 of the class file verifier.

Certain instructions and data types complicate the data-flow analyzer. We now examine each of these.

Long Integers and Doubles

Whenever a long or double is moved into a register, the following register is marked as containing the second half of a long or double. This special value indicates that all references to the long or double must be through the lower numbered register.

Whenever any value is moved to a register, the preceding register is examined to see if it contains the first word of a long or a double. If so, that preceding register is changed to indicate that it now contains an unknown value. Since half of the long or double has been eradicated, the other half can no longer be used.

Dealing with 64-bit quantities on the stack is simpler. The verifier treats them as single units on the stack. For example, the verification code for the dadd opcode (add two double floats) checks that the top two items on the stack are both double floats. When calculating stack length, longs and double floats on the stack have length two.

Stack manipulation opcodes must treat doubles and longs as atomic units. For example, the verifier reports a failure if the top element of the stack is a double float and it encounters the opcodes pop or dup. The opcodes pop2 or dup2 must be used instead.

Constructors and Newly Created Objects

    new myClass(i, j, k);

    new <myClass>            # allocate uninitialized space
    dup                      # duplicate object on the stack
    <push arguments>
    invokenonvirtual myClass.<init>  # initialize

The myClass initialization method sees the new uninitialized object as its this argument in register 0. It must either call an alternative myClass initialization method or call the initialization method of a superclass on the this object before it is allowed to do anything else with this.

In normal instance methods (what C++ calls virtual methods), the verifier indicates that register 0 initially contains an object of "the current class"; for constructor methods, register 0 instead contains a special type indicating an uninitialized object. After an appropriate initialization method is called (from the current class or the current superclass) on this object, all occurrences of this special type on the stack and in the registers are replaced by the current class type. The verifier prevents code from using the new object before it has been initialized and from initializing the object twice.

Similarly, a special type is created and pushed on the stack as the result of the opcode new. The special type indicates the instruction in which the object was created and the type of the uninitialized object created. When an initialization method is called on that object, all occurrences of the special type are replaced by the appropriate type.

The instruction number needs to be stored as part of the special type since there may be multiple instances of a non-yet-initialized type in existence on the stack at one type. For example, the code created for the following:

    new InputStream(new Handle(),new InputStream("foo"))

Code may not have an uninitialized object on the stack or in a register during a backwards branch, or in a register in code protected by an exception handler or a finally. Otherwise, a devious piece of code could fool the verifier into thinking it had initialized an object when it had, in fact, initialized an object created in a previous pass through the loop.

Exception Handlers

• The range of instructions protected by two different exception handlers will always either be completely disjoint or one will be a subrange of the other. There will never be a partial overlap.
• The handler for an exception will never be inside the code that is being protected.
• The only entry to an exception handler is through an exception. It is impossible to fall through or "goto" the exception handler.

Try / Finally

    try {
        startFaucet();
        waterLawn();
    } finally {
        stopFaucet();
    }

To implement this construct, the Java compiler uses the exception handling facilities, together with two special instructions, jsr (jump to subroutine) and ret (return from subroutine). The cleanup code is compiled as a subroutine. When it is called, the top object on the stack will be the return address; this return address is saved in a register. At the end of the cleanup code, it performs a ret to return to whatever code called the cleanup.

To implement try/finally, a special exception handler is set up around the protected code which catches all exceptions. This exception handler:

1. Saves the exception in a register.
2. Executes a jsr to the cleanup code.
3. Upon return from the exception, re-throw's the exception.

1. Saves the return value (if any) in a register.
2. Executes a jsr to the cleanup code.
3. Upon return from the exception, returns the value saved in the register.

The cleanup code presents a special problem to the verifier. Usually, if a particular instruction can be reached via multiple paths and a particular register contains incompatible values through those multiple paths, then the register becomes unusable. However, a particular piece of cleanup code might be called from several different places:

• The call from the exception handler will have a certain register containing an exception.
• The call to implement "return" will have some register containing the return value.
• The call from the bottom of the protected code may have trash in that same register.

Verifying code that contains finally's can be somewhat complicated. Fortunately, most code does not have finally's. The basic idea is the following:

• Each instruction keeps track of the smallest number of jsr targets needed to reach that instruction. For most code, this field will be empty. For instructions inside cleanup code, it will be of length one. For multiply-nested cleanup code (extremely rare!), it may be longer than one.
• For each instruction and each jsr needed to reach that instruction, a bit vector is maintained of all registers accessed or modified since the execution of the jsr instruction.
• When executing the ret from a subroutine, there must be only one possible subroutine target from which the instruction can be returning. Two different targets of jsr instructions cannot "merge" themselves into a single ret instruction.
• When performing the data-flow analysis on a ret instruction, modify the directions given above. Since the verifier knows the target of the jsr from which the instruction must be returning, it can find all the jsr's to the target, and merge the state of the stack and registers at the time of the ret instruction into the stack and registers of the instructions following the jsr using a special set of values for the registers:
• For any register that the bit vector (constructed above) indicates that the subroutine has accessed or modified, use the type of the register at the time of the ret.
• For other registers, use the type of the register at the time of the preceding jsr instruction.

Conclusion

However, before users will consent to bring over executable code from untrustworthy sources (i.e. most of the network!), they want assurances that the code cannot damage them. The byte-code verifier is the lowest-level of a many-tiered strategy [10].

Acknowledgments

References

2. James Gosling and Henry McGilton. The Java Language Overview: A White Paper. Sun Microsystems Technical Report, May 1995. Available via http://java.sun.com/whitePaper/javawhitepaper_1.html

3. Donald E Knuth. The Art of Computer Programming, volume 1: Fundamental Algorithms. Addison-Wesley, Reading, Massachusetts, 1969.

4. The HotJava Overview. Available via http://java.sun.com/1.0alpha3/doc/overview/hotjava/index.html

5. The Java Virtual Machine Specification. Available via http://java.sun.com/1.0alpha3/doc/vmspec/vmspec_1.html

6. The Unicode Consortium. The Unicode Standard: Worldwide Character Encoding. Addison-Wesley, Reading, Massachusetts, 1992. Available via http://unicode.org/

7. Alfred V.Aho, Ravi Sethi,, and Jeffrey D Ullman. Compilers: Principles, Techniques, and Tools. Addison-Wesley, Reading, Massachusetts, 1988

8. Samuel P. Harbison. Modula-3. Prentice-Hall, Inc. 1992.

9. Guy L. Steele Jr. Common Lisp: The Language, Second Edition. Digital Press, Bedford, Massachusetts, 1990. Available via http://www.cs.cmu.edu/Web/Groups/AI/html/cltl/cltl2.html.

10. HotJava(tm): The Security Story. Available via http://java.sun.com/1.0alpha3/doc/security/security.html

About the Author

Generated with CERN WebMaker