There is a tightrope to walk in this chapter. You should understand the problems encountered with Java, so you know how things can go wrong, especially if you are charged with designing security-critical systems, administering a large number of Java users, or making business decisions that depend on Java security issues. But it is not the intent of this book to give the bad guys a manual for invading your computer. Although we discuss Java security problems, we hope you forgive the omission of details necessary to exploit these problems. Just for the record, we do not believe in security by obscurity. If we did, we would not have written this book at all. However, we don't believe in publishing exploit scripts and aiding and abetting attacks by inexperienced would-be crackers, either. Serious Java attacks have yet to escape the lab, and we want to do our part to keep it that way. In the early days of Java, Sun Microsystems and the rest of the Java industry hyped Java as completely secure [Sun Microsystems, 1995]. This was really no surprise. They still have a lot to gain if you believe them and jump aboard the Java bandwagon without even considering the risks of doing so. It's true that Sun Microsystems, Netscape, Microsoft, and others have gone to great lengths to make their Java implementations as secure as possible. That's all well and good, but you don't want effort-you want results. To this day, the question remains: Is Java safe enough to use? This chapter examines all of the serious security flaws that have been found in Java so far. By serious, we mean attacks based on these flaws could go beyond the annoyance or denial-of-service attacks of Chapter 4, "Malicious Applets: Avoiding a Common Nuisance." These attacks could corrupt data on your hard disk, reveal your private data to third parties, turn your machine into a hostile listening post, or infect your machine with a virus. By exploiting some of the vulnerabilities discussed here, a cracker could attain the ultimate cracker goal-complete control of your machine. Java vendors are very quick to fix any problems that are discovered in Java. In fact, vendor response to the discovery of a new Java security hole far surpasses the usual response to non-Java-related security problems posted to Bugtraq and other mailing lists run by security professionals (Bugtraq archives are available at www.geek-girl.com/bugtraq/). In terms of Java, the penetrate-and-patch machine is smoothly oiled (not that it represents the best approach to security, but that's another issue). Rest assured that the problems we discuss in this chapter have been fixed in the latest JVMs, including those packaged in Java-enabled browsers. That means if you're using an up-to-date version of your favorite browser, these specific problems won't affect you. On the flip side, if you're using an older browser like Netscape 2.x/3.x or Internet Explorer 3.x, this chapter provides enough information about serious attacks that you really should upgrade immediately. Browsers are not patched; they are made obsolete through accelerated release of new versions. Using an old browser to surf the Web is like wearing a "kick me" sign to a fraternity party. Though these specific attacks are not likely to be your problem since they have been fixed, they indicate what sorts of things can go wrong and what the consequences are when things do go wrong. If more Java security problems are found in the future, they're likely to be similar to the ones presented here. Hopefully the industry can learn from its old mistakes and avoid reintroducing old holes (as often happens in computer security). Most of these problems were trivial to fix once they were discovered. Removing security bugs is like removing needles from a haystack: It's hard to find the needles, but they're easy to remove once you know where they are. To push the analogy a bit: It's obviously much better to find the needles before they stick you. This principle motivates our Java security research.
Chapter... Preface -- 1 -- 2 -- 3 -- 4 -- 5 -- 6 -- 7 -- 8 -- 9 -- A -- B -- C -- Refs
Copyright ©1999 Gary McGraw and Edward Felten. |
