The designers of Java tried to ensure that applets could not misbehave. Although they often claim success (with apologies to Mr. Clemens) claims about Java's security have been greatly exaggerated. Lately, the security message emanating from the major vendors has tended to emphasize the idea of managing risks. That's good. We live with risks every day, and there is no reason we can't live with mobile code risks, especially if we take on the risks with our eyes open and some forethought about possible consequences. All implementations of Java have had some rather serious security flaws. Even "mature" implementations including Java 2 are not perfect. All known attacks have been detailed in this chapter. So the question is what to do as we face these risks. Turning Java off is certainly one solution, but not a very satisfying one. Java has lots to offer, and not using it would probably be a poor decision in the long run. The new Java 2 security model, with its emphasis on policy, may help make Java risks easier to manage. The trick is setting up a sound policy that makes sense for your organization. Each of the security problems that we discussed in this chapter can be implemented as an attack applet. In fact, the Princeton team regularly creates attack applets in the lab to test the limits of Java's vulnerabilities.4 Although rumor has it that attack applets based on the DNS bug and the Princeton Class Loader attack have appeared on underground Web sites, there is no convincing evidence that such attack applets have ever been used to crack a system on the Net. Nonetheless, the main reason attack applets need to be taken very seriously is that the end result of a successful attack is full system penetration; in other words, attack applets are capable of aiding a cracker in taking over your machine. Once you no longer "own" your machine, a cracker can install a virus, erase your hard disk, place Trojan Horses and logic bombs, or maybe just spy on you and steal your credit card information, bank account number, business plans, or personal correspondence. Java brings the formidable power of mobile code to the Web. Trading security for this power is a tough pill to swallow, but a pill that's probably worth ingesting. Users want audio/visual conferencing without cross-network eavesdropping. Users want loosely coupled computation for things like factoring without cycle theft and denial of service. Users want games without Trojan Horses. Users want save and restore for applet-based preferences without having their valuable files stolen. Being security conscious, users can probably have what they want, without getting anything that they don't need.
Chapter... Preface -- 1 -- 2 -- 3 -- 4 -- 5 -- 6 -- 7 -- 8 -- 9 -- A -- B -- C -- Refs
Copyright ©1999 Gary McGraw and Edward Felten. |
