The second set of attacks involves Java code that passes itself off as belonging to the browser. In early versions of the JDK (before Java 2), code that came with the browser was assumed to be safe (see Chapter 2 and [McGraw and Felten, 1996]). The original built-in code distinction was scrapped with the introduction of code signing, and these days very little code is trusted (see Chapter 3). In any case, the Slash and Burn fraud allows the malicious code access it would not ordinarily have. It could, for example, access files on the local disk. In order to properly understand this attack, you need to understand how Java works. In particular, examine how Java accesses its own code on the browser's local disk.
When a Java applet runs, many Java classes (pieces of Java code) are loaded and run. Some applet-related classes are loaded by the applet, using the Web server. Other classes are part of the browser itself. Browser-related code is stored with the browser on the local disk. Netscape, for example, keeps its Java class files zipped up in an archive called classes.zip. When Netscape is installed, the class archive needs to be put somewhere special, like /usr/local/lib/netscape on Unix machines. Because the browser classes were considered part of the trusted browser program, they were given more privileges. (This is no longer the case.) In general, before JDK 1.1, Java treated code loaded from the local disk as trusted, and code loaded over the Net as untrusted. That meant if an attacker could somehow get some malicious code loaded from the local disk, the attacker was home free. The original system was changed significantly with the introduction of JDK 1.0.2, which stopped treating code loaded off the disk as trusted. This change was made behind the scenes with little fanfare. As the Cache Cramming attack (explained later) shows, many people were confused by the change. From our discussion of the Java class loader in Chapter 2, we know that when Java needs to find a piece of code, say, for a class MyClass, it first looks on the local disk for a file called MyClass.class. If Java fails to find an appropriate file on the local disk, then it tries to fetch the file from the Web server that originally provided the applet. We've glossed over one key issue at this point: How does Java know what class to look for? The answer is that a class is only loaded when it is mentioned by another class already resident. This is called dynamic loading. The name of the mentioned class is stored in the Java code for the mentioning class. Java classes have names like security.book.chapter5. When the Java system wants to look up a class on the disk, it translates the dots in the class name into backslashes. The name security.book.chapter5 becomes security\book\chapter5.2 This transformed name is the filename used to search for the file on the local disk.
If a bad guy wants to pass off a piece of code as trusted (in systems before JDK 1.0.2), two steps must be carried out: 1) Get the malicious code onto the victim's disk, and 2) Trick the victim's browser into loading it. The first part, getting code onto the victim's disk, isn't as difficult as it sounds. For example, some machines have public FTP directories, where anyone can put a file. Alternatively, if the victim is using a shared, public machine, the attacker could get an account on that machine and put the file in that account's home directory. Perhaps the most effective way to inject code is to take advantage of the browser's cache. Most Web browsers keep on-disk copies of recently accessed files. This allows repeated accesses to the same Web documents without continually downloading the documents. Unfortunately, it also gives a malicious applet a way to get a file onto the victim's machine. The applet could load the file across the Net, pretending that it was an image or a sound file. Once this was done, the file would be on the victim's disk in the cache. If the applet knew how the browser organized its cache, it would know where on the victim's disk the file resided. This sneaky trick makes a second appearance in the Cache Cramming attack as well (see page 171). Once the file is on the victim's disk, the attacker tricks the victim's browser into loading the file. Since the browser only looks up classnames in relation to the current directory, the attacker would have to place a file into the victim's working directory. Filename lookup is relative because Java classnames cannot start with a dot; therefore, the translated name cannot start with a backslash. David Hopwood discovered that Java 1.0.1 and Netscape Navigator 2.01 erroneously allowed a classname to start with a backslash. Such a classname could reference any file on the system, not just those files associated with the browser. For example, a class named \programs.browser.cache.file407 would be looked up on the local disk as \programs\browser\cache\file407. This trick could be used to cause any file on the local disk to be loaded as Java code. Because code loaded from the local disk was trusted (pre-JDK 1.0.2), it could proceed to illegally access the local system. This attack allows full system penetration-the bad guy can do anything at all on the victim's machine.
This problem was fixed in Netscape Navigator 2.02 and in all Java-enabled versions of Microsoft Internet Explorer. The fix was simple: Prohibit classnames from starting with backslashes (or slashes, as the case may be). It is no longer possible to execute impostor code using the Slash and Burn attack.
Chapter... Preface -- 1 -- 2 -- 3 -- 4 -- 5 -- 6 -- 7 -- 8 -- 9 -- A -- B -- C -- Refs
Copyright ©1999 Gary McGraw and Edward Felten. |
