To date, 16 serious security problems have been discovered in implementations of Java. Table 5.1 lists the holes and their accompanying exploits by name. A brief chronology follows that describes each flaw. These flaws will be discussed in more detail later in this chapter. Some of these flaws allow full system penetration. This means that an attacker could exploit them to do literally anything to your machine, including corrupting your data, reading your private data, injecting a virus, or leaving a trapdoor to reenter your machine at will.
February 1996: Drew Dean, Edward Felten, and Dan Wallach at Princeton discovered a flaw in Java's networking software, affecting Netscape Navigator 2.0. This flaw was postulated independently by Steve Gibbons. It could be exploited to launch security attacks on other machines on a private network. This flaw was fixed in Netscape Navigator 2.01. The resulting attack is called Jumping the Firewall. See page 147. This attack resulted in one of the two Java-related CERT alerts [CERT, 1996a]. March 1996: David Hopwood at Oxford University found a flaw that allows an attack that tricks Java into treating the attacker's applet as trusted code. This flaw allowed full system penetration. It affected Netscape Navigator 2.01 and was fixed in Netscape Navigator 2.02. The resulting attack is called Slash and Burn. See page 153. March 1996: The Princeton team (Dean, Felten, and Wallach) found a bug in the Java byte code Verifier and a flaw in the class-loading mechanism. Together, these allowed full system penetration. This problem affected Netscape Navigator 2.01 and was fixed in Netscape Navigator 2.02. The resulting attack is called Applets Running Wild. See page 158. This attack resulted in the second of the two Java-related CERT alerts [CERT, 1996b]. May 1996: Independent consultant Tom Cargill, working with the Princeton team (Dirk Balfanz, Dean, Felten, and Wallach) found a flaw in the implementation of the Java interpreter. This flaw allowed full system penetration. It affected Netscape Navigator 2.02 and Microsoft Internet Explorer 3.0beta1, and was fixed in Navigator 3.0beta3 and Explorer 3.0beta2. The resulting attack is called Casting Caution to the Wind. See page 163. June 1996: Hopwood found another flaw in the interpreter that again allowed full system penetration. This flaw affected Netscape Navigator 3.0beta3 and was fixed in Navigator 3.0beta4. The resulting attack is called Tag-Team Applets. See page 165. June 1996: Balfanz, Dean, and Felten found a flaw in Java's implementation of array types that allowed full system penetration. This flaw affected Netscape Navigator 3.0beta5 and was fixed in Navigator 3.0beta6. The resulting attack is called You're Not my Type. See page 156. July 1996: Cargill, Balfanz, Dean, and Felten found another implementation flaw in the Java interpreter. This flaw allowed an attacker to mount some attacks on network services on other private-network machines. This flaw affected Netscape Navigator 3.0beta5 and was fixed in Navigator 3.0beta6. This attack is also called Casting Caution to the Wind. See page 163. August 1996: Balfanz and Felten found a flaw in Microsoft's Java implementation. The flaw allowed code in an attack applet to become a member of a security-critical Java package, thus gaining the ability to change various security parameters. This in turn gives the applet full access to the target machine's files and the network. This flaw affected Microsoft Internet Explorer 3.0beta3 and was fixed in Explorer 3.0beta4. The resulting attack is called Big Attacks Come in Small Packages. See page 167. February 1997: A pair of British hacker/consultants, Ben Laurie and Major Malfunction, discovered two separate flaws, one that worked only against Netscape Navigator 3.x and the other that worked only against Microsoft Internet Explorer 3.x. The Microsoft flaw was much more serious than the Netscape flaw. The fact that the attacks were browser specific serves to emphasize that different vendors have different approaches to implementing Java security. To be sure, both vendors are coding to the same specification, but there are many ways to skin a cat. The two attacks are called, Steal This IP Number and Cache Cramming, respectively. See pages 169 and 171. March 1997: Security researchers at JavaSoft discovered a subtle error in the JVM and immediately patched it. This illustrates how serious JavaSoft is about security. The error was deep inside the Virtual Machine code and affected all browsers. The attack is called Virtual Voodoo. See page 172. April 1997: Soon after the release of JDK 1.1, the Princeton team discovered a serious flaw in the newly implemented code-signing system. The flaw allowed an attack applet to take on maximum privilege allocated inside a system. Because only the HotJava browser supported JDK 1.1, it was the only browser affected by the flaw. This attack is called The Magic Coat. See page 172. May 1997: The Kimera group at the University of Washington, led by Professor Brian Bershad, created a byte code Verifier of their own using formal methods and strict software engineering processes. In order to test their implementation, the Kimera group created an automatic test harness that generated millions of tests by mutation. They then tested their Verifier against commercially available Verifiers. In the course of testing, they identified 27 errors in various commercial Verifiers. One error was severe enough to warrant a patch. The others were patched in later releases of the JDK. This set of attacks is called Verifying the Verifier. See page 174. July 1997: Sun's response to the Verifier errors in May (which downplayed their severity) prompted the Kimera group to create an exploit that attacked Netscape Navigator 3.x. The attack was able to gain access to protected information in the browser's memory space, including private keys used in setting up secure socket layer (SSL) sessions. This attack is called the Vacuum Bug. See page 177. August 1997: Creative Concepts consultant Ben Mesander discovered a weakness in the way HTTP redirect operations were handled by Java. The weakness was particularly obvious in Microsoft Internet Explorer 3.x but was also present (in a subtler fashion) in Netscape Navigator 3.x. This attack is called Look Over There. See page 178. July 1998: Balfanz, Dean, Felten, and Wallach found a security flaw in the ClassLoader implementation of JDK 1.1 and JDK 1.2beta3 that allows a malicious ClassLoader to override the definition of built-in "system" types like java.lang.Class. When properly abused, this can lead to a type confusion attack that completely compromises security. The flaw requires use of a secondary flaw to gain a foothold. Mark LaDue had earlier discovered such a flaw in Netscape 4.0x's Security Manager. Thus, Netscape 4.0x is exploitable, while other Java VMs (Sun's and Microsoft's) do not appear to be exploitable even though they contain the same flaw. This attack is called Beat the System. See page 182. The rest of this chapter describes these flaws in more detail.
The chronology presented here has an interesting meta-level property. Both in August 1996 and in August 1997 several months followed in which no major security holes were discovered. Interestingly, the period of six months in late 1996 was of long enough duration that some Java evangelists began to claim that all Java holes had been discovered and that Java was completely secure. They were wrong. First of all, anyone who claims any program or programming language is completely secure should be viewed with suspicion. There is no such thing as 100-percent security; the best we can do is minimize risk. This goes for Java as well as any other computer system. Fortunately, Java mitigates many risks that competing systems of mobile code like ActiveX and JavaScript do not (see Chapter 1, "Mobile Code and Security: Why Java Security Is Important," for details). This makes Java more secure than those systems, but it does not make Java perfectly secure. Short of proving Java correct (which is unlikely ever to happen given the state of formal methods), we must live with potential security holes. Second, the pattern in the chronology corresponds with major releases of the JDK. The gap between August 1996 and February 1997 included the time period when JDK 1.02 was in common use and JDK 1.1 had not yet been released. As soon as JDK 1.1 was released, some new holes were discovered. The same sort of gap appeared as Java 2 slowly trickled out. This reflects two facts: 1) each major release includes much new functionality, and 2) Java is complicated, and complicated systems always include room for error. From these facts, it is natural to infer that the discovery of holes will coincide with major releases.
Chapter... Preface -- 1 -- 2 -- 3 -- 4 -- 5 -- 6 -- 7 -- 8 -- 9 -- A -- B -- C -- Refs
Copyright ©1999 Gary McGraw and Edward Felten. |
