You're Not My Type (Ch. 5, Sec. 7) [Securing Java]

Attack Applets: Exploiting Holes in the Security Model
CHAPTER SECTIONS: 1 / 2 / 3 / 4 / 5 / 6 / 7 / 8 / 9 / 10 / 11 / 12 / 13 / 14 / 15 / 16 / 17 / 18 / 19 / 20

Section 7 -- You're Not My Type

As discussed in Chapter 2, the most common kind of serious security problem in Java involves type confusion. A type-confusion attack confuses the Java system about the types of data objects it is manipulating.

The Java system treats objects as blocks of memory. Allocated memory contains the data fields of all objects, lined up one after the other. When a Java program has a reference to an object, what it really has internally is a pointer to the memory address storing the object. You can think of the pointer as tagged with a type that says what kind of object the pointer is pointing to.

As mentioned in Chapter 2, every aspect of Java security depends critically on the type-safety of the language. This means that if Java is going to be secure, it has to make sure that all pointers are properly tagged; that is, the tag must match the actual type of object that is being pointed to.

In a type-confusion attack, a malicious applet creates two pointers to the same object-with incompatible type tags. When this happens, the Java system is in trouble. The applet can write into that memory address through one pointer, and read it through another pointer. The result is that the applet can bypass the typing rules of Java, completely undermining its security.

Figure 5.4 shows a type-confusion attack at work. The applet has two pointers to the same memory: one pointer tagged with type T and one tagged with type U. Suppose that T and U are defined like this:

class T {
     SecurityManager x; 
}

class U {
     MyObject x;
}

Now the applet can run code like this:

T t = the pointer tagged T;
U u = the pointer tagged U;
t.x = System.getSecurity(); // the Security Manager
MyObject m = u.x;

The result is that the object ends up with a pointer, tagged as having type MyObject, to the memory representing Java's Security Manager object. By changing the fields of m, the applet can then change the Security Manager, even though the Security Manager's fields have been declared private.

While this example showed how type confusion can be used to corrupt the Security Manager, the tactic may be exploited to corrupt virtually any part of the running Java system.

Figure 5.4 Type-confusion attack.
Two of the objects in the reference table, t and u, are supposed to be of different types, but actually reference the same object in memory.

An Example of Type Confusion

Drew Dean discovered a typical type-confusion attack, based on Java's handling of array types. Java allows a program that uses a type T to use the type array of T. These array types are not explicitly declared by the programmer, but exist automatically. The Java Virtual Machine defines them automatically when they are needed.

These array types are defined by the VM for internal use. Java gives them a name beginning with an open square bracket ([). As this character is not allowed to be the first character of a programmer-defined classname, there is no danger of conflict.

Dean discovered, however, that in Netscape Navigator 3.0beta5, a Java byte code file could declare its own type name to be one of the special array type names. Attempting to load such a class would generate an error, but the Java VM would install the name in its internal table anyway.

This redefined one of Java's array types and created a classic type-confusion scenario: Java considered the object an array, but it actually had some other type. The result was full system penetration. This problem was fixed in Navigator 3.0beta6.

The Type-Confusion Toolkit

The Princeton team, as a feasibility demonstration, created a toolkit that allows any type-confusion attack to be turned into a disarming of Java's security. In other words, the toolkit serves as a way of turning a small security breach into a complete system penetration. The type-confusion toolkit has not been released to the public and is considered too dangerous to describe in any detail here. The toolkit was recently revised to work against Java 2 systems.

Chapter... Preface -- 1 -- 2 -- 3 -- 4 -- 5 -- 6 -- 7 -- 8 -- 9 -- A -- B -- C -- Refs
Front -- Contents -- Help