Securing Java

Previous Page
Previous Page
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 19 -- Beat the System

Next Page
Next Page

In July 1998, Dirk Balfanz, Drew Dean, Edward Felten, and Dan Wallach of Princeton's Secure Internet Programming team found another Java security flaw that allows a malicious applet to disable all security controls in Netscape Navigator 4.0x. After disabling the security controls, the applet can do whatever it likes on the victim's machine, including arbitrarily reading, modifying, or deleting files. As usual, the Princeton team implemented a demonstration applet that deletes a file.

The hole that the Princeton Team discovered was actually present in all VM's, but was only exploitable in Netscape 4.0x. This serves to emphasize the difference between holes and exploits discussed earlier in the chapter (see page 142). Figure 5.7 illustrates the relationship between a security hole and an attack applet that exploits the hole.

Fig 5.7

Figure 5.7 Security holes and exploits.

An attack applet is created to exploit one or more security holes in order to completely compromise security.

This attack pieced together several security-related flaws. The first flaw, discovered by Mark LaDue, is that the Netscape 4.0x Security Manager does not prevent untrusted applets from creating subclasses of Netscape's AppletClassLoader class. This allows an applet to create a Class Loader.

The second flaw, discovered by the Princeton team, is that the class loader mechanism, as of JDK 1.2beta3 and Netscape 4.0x (and, apparently, Internet Explorer 4.01), sometimes allows a malicious Class Loader to override the definitions of built-in classes. Specifically, a Class Loader can use its defineClass() method to define classes that have the same name as any built-in class, provided that the built-in class being overridden has not yet been loaded into the Class Loader's namespace.

Since the correct operation of the Java VM depends in part on the correct behavior of built-in classes like java.lang.Class, java.lang.Object, and java.lang.Exception, a Class Loader that can override the definitions of built-in classes can change the rules of the Java VM.

The third flaw is a subtle bug in the Verifier that opens a window of vulnerability for the class-overriding trick. The details of this third flaw are a bit too sensitive to publish here. Suffice it to say that the Verifier assumes that only certain types of objects can appear on the stack in some special situations, and that class-overriding allows an attacker to violate this assumption.

The combination of these three flaws allows an attacker to create type confusion, which leads to a full-blown security breach as usual.

Class Loading Take Four

One instructive thing about this attack is the role of class loaders. Several previous attacks have exploited class loader problems, and this attack shows that the class loader design was still not right, even after several iterations. Indeed, the problem of designing a correct class loader API is a subject of research by Drew Dean at Princeton [Dean 1997], leading to a major portion of Dean's Ph.D. thesis. The problems with class loaders are perhaps the best counter-argument to those who say that Java's security problems have been superficial implementation bugs. Fixing these problems is hard enough to merit a Ph.D. thesis!

This flaw is fixed in Netscape Navigator 4.5.

Previous Page
Previous Page

The Web

Next Page
Next Page

Menu Map -- Text links below

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

Copyright ©1999 Gary McGraw and Edward Felten.
All rights reserved.
Published by John Wiley & Sons, Inc.