We now describe an attack applet that exploits a Java security weakness in beta versions of Microsoft's Internet Explorer 3.0. The weakness allows code in an untrusted applet to pass itself off as part of a Java package. This flaw allows an attacker to gain full access to the victim's files and to the network. Understanding this flaw requires a more detailed explanation of Java packages.
The Java language supports the concept of packages-groups of Java classes meant to be used together. Packages have names like java.lang and EDU.princeton.cs.sip. Every Java class belongs to some package. Packages serve two purposes. First, since the full name of a class is the package name followed by the classname, they provide a way for different people to name their classes without having accidental name collisions. For example, if we put all of our classes into the authors package and you put all of your classes into the readers package, then our classnames cannot collide with yours. The second purpose of packages is to restrict access to certain Java variables. When declaring a variable, a programmer states which classes are allowed to access the variable. If the variable is declared private, it is accessible only by the class that created it. If a variable is declared protected, it is accessible only by the creating class and its subclasses. If a variable is declared public, it is accessible by all classes. If a variable is declared neither private, protected, nor public, then it is accessible only by classes in the creating class's package. Some packages limit their membership to only built-in browser classes. Membership is restricted by having the Virtual Machine ask the Security Manager to pass judgment on every request to join a package. The Security Manager enforces restrictions by prohibiting classes loaded across the Net from joining restricted packages. (For more information on this topic, see Chapter 2.)
In Microsoft's browser, there was an error in the way the Security Manager made its decisions about package membership. Because of the bug, the Security Manager incorrectly used only the first component of the package name to check access permission. This method failed for packages whose names started with com.ms. Interestingly, several of Microsoft's built-in packages started this way. (This is interesting because the domain name ms.com belongs to Morgan Stanley, not to Microsoft. The package should have been called com.microsoft, although this change would not have prevented the bug.) The result was that untrusted applet code could join a sensitive package, and gain access to any variables in that class that were accessible package-wide. These variables included, among other things, the Security Manager's list of files to which the applet had access. A mischievous applet could access any file on the system by changing the Security Manager's list to include the desired file.
This flaw was found just before Microsoft was to ship the first nonbeta version of their Internet Explorer 3.0 browser. Since the ship date had been announced (and a big public release hoopla was planned), the ship date could not be moved. Since the product had a serious security flaw, shipping it was not an acceptable alternative. Microsoft's development team launched a heroic effort to fix the bug, test the solution, and restart the product release cycle in time to meet the original release deadline. They succeeded. The Big Attacks Come in Small Packages bug was the last major flaw found in the JDK 1.0.2 security model implementations. Following discovery of this attack applet, several months went by before JDK 1.1 was released. As we discussed earlier, the period of six months without a major security hole was of long enough duration to convince some people (in particular, Java's most ardent supporters) to declare that all holes had been discovered and that Java had been rendered secure through a series of patches. In fact, the previous version of this book was waved around as a prime example of antiquated old news that no longer applied. Even if another hole is never discovered in Java (unlikely, but why not dream big?), the information contained in this chapter is important to people charged with designing, managing, and using software in a security-critical situation. We all do well to learn from our mistakes as history often tends to repeat itself.
Chapter... Preface -- 1 -- 2 -- 3 -- 4 -- 5 -- 6 -- 7 -- 8 -- 9 -- A -- B -- C -- Refs
Copyright ©1999 Gary McGraw and Edward Felten. |
