The next group of attacks combines the two previous attack methods. By setting up two separate naming environments and passing objects between them, this new group of attacks causes type confusion, leading to security breaches. These attacks are launched by putting two applets on a Web page and having the two applets cooperate. Typically, both applets would be written by the same programmer, and located on the same Web server. To better understand this threat, the next section will examine in further detail how Java manages namespaces. (See also Chapter 2.)
In a Java-enabled browser, several applets might be running at the same time. Since each applet contains several classes, each with a distinct name, there's a danger that two applets might accidentally use the same name. To prevent this, the Java designers decreed there should be a separate namespace for each applet; that is, each applet should have its own view of which names correspond to which classes. Despite the fact that each applet has its own namespace, there are ways for two applets to pass objects back and forth among themselves. One such channel involves public variables in the Java runtime. Another channel is through manipulating threads. The result is that an applet can potentially have an object whose name is defined in another namespace. Things can get tricky when this happens. For example, suppose that the AncientGreek applet and the Simpsons applet are running at the same time. Each of the two applets has defined a class called Homer, but they have very different ideas of how Homer should behave. Worse yet, imagine that the two applets communicate, and the AncientGreek applet ends up with a Homer Simpson object. If the AncientGreek applet asks the object what its class is, the object responds, Homer. The AncientGreek applet then asks Homer to recite an epic poem. Depending on your point of view, the result would be either tragic or comical. In any case, it wouldn't be what the programmers wanted. This isn't really a security risk; however, it becomes one if the Java system itself gets confused. The danger is that the system will decide that two unlike types are really the same, when all that is the same is their names. This sort of mix-up would constitute type confusion, and the applet could break the Java type system, leading to a security breach. One way that an applet could do this is by engaging in type punning. The applet would set up two types with the same name, create an object of one type, and then use it as though it were an object of the other type. For example, suppose that this is a Java type:
Another applet could create another type with the same name:
Now if the applet could get an object of the real Secure class and convince Java that the object belonged to the impostor Secure class, Java would allow the applet to access the supposedly private secretData field. As far as Java is concerned, this would be fine. The impostor secretData field is public. The applet would have accessed data it was not supposed to see. Type punning works for method calls, too. If the secretData field were replaced with a dangerousOperation method, then an applet that could do type punning could call the dangerousOperation method even though it was supposed to be private. In summary, if type punning is possible, Java's security collapses. Java prevents type punning by being very careful when deciding whether two classes are the same. Rather than using the classname to make this decision, Java considers two classes the same only if they have the same name and were defined in the same namespace (that is, by the same Class Loader). That is sufficient protection to avoid type punning.
Unfortunately, the creators of Java were not always so careful. In Java 1.0.2, Netscape 2.02, and the first beta version of Internet Explorer, the types of interfaces and exceptions were compared by name rather than by (name, namespace) pair as required. This led to a set of attacks that could break Java's security system, achieving full system penetration. The attacks worked as described earlier. The attacker wrote two applets defining different classes with the same name C. One applet would create an object of class C and pass it to the other applet, which would operate on its C. This leads to a classic type-confusion situation, which can be exploited by methods seen several times in this chapter.
Chapter... Preface -- 1 -- 2 -- 3 -- 4 -- 5 -- 6 -- 7 -- 8 -- 9 -- A -- B -- C -- Refs
Copyright ©1999 Gary McGraw and Edward Felten. |
