Chapter 2, "The Base Java Security Model: The Original Applet Sandbox," and Chapter 3, "Beyond the Sandbox: Signed Code and Java 2," explain how Java 2's security system works. This chapter and the next explain how it doesn't. Unfortunately, it is entirely possible to (mis)use Java, especially in its applet form, as a vehicle for attacking systems. Language-based security controls like those found in Java make writing a hostile applet more difficult than it might be otherwise, but they don't make it impossible. (Recall that Java security stacks up favorably against competing mobile code systems like ActiveX, as we discussed in Chapter 1, "Mobile Code and Security: Why Java Security Is Important.") Applets that misbehave and do something that their users don't want to happen are called hostile applets. There are two varieties of hostile applets: malicious applets and attack applets. The names of the two classes make it clear which is the more serious variety. Fortunately, attack applets are not commonly encountered on the Web; in fact, no attack applets have been seen to date in the wild (that is, outside the labs in which they were created). That's not to say that attack applets are not real. They are. Attack applets are real applets, written in everyday Java, that work against popular browsers such as the one you use. Attack applets have been created and extensively tested in the laboratory. (We return to the subject of attack applets in Chapter 5, "Attack Applets: Exploiting Holes in the Security Model.") There is, however, another more pervasive kind of hostile applet, not as serious a security concern, but still worthy of attention-the malicious applet. Unlike their attack applet cousins, malicious applets have escaped the lab. Such realities make it necessary for all users of Java-enabled browsers (and their trusty system administrators) to be aware of Java security threats. Simply surfing over to a Web page containing a hostile applet allows it to invade your machine with its malicious code. This chapter explores many malicious applets, ranging from the merely annoying to the more seriously disturbing. Near the beginning of Chapter 2, classes of potential Java threats were discussed. The four classes of attacks named were system modification attacks, invasion of privacy attacks, denial of service attacks, and antagonistic attacks. Java is a powerful enough language that, without security constraints placed on applets, it is possible to implement all four such classes of attacks. The Java security model was designed to thwart those threats perceived to be the greatest dangers. Much ado has been made over Java security problems, and there have in fact been a number of serious flaws. We detail the truly serious problems in Chapter 5. Such problems result in intrusions that allow arbitrary system modification (effectively, unlimited access). An attack applet based on one of these strategies constitutes a cracker breaking into your machine. It is true that the very serious attacks of the next chapter require an in-depth understanding of both Java and the Internet. It has been argued that we should feel fairly confident that few people will be able to exploit such esoteric vulnerabilities. That position is a dangerous one to take. One instance of a cracker discovering a novel attack applet will change such statements considerably. Once loose, attack applet information would quickly spread throughout the cracker community. Our job as security researchers is to find security holes and plug them before they are used by dishonest people. Security researchers also work to create such a secure model that holes are very rare. Fortunately, none of the serious attacks have shown up in the form of attack applets, although the possibility looms ominously. Don't breathe a sigh of relief yet. Tampering with Java security does not always require wizardry. In fact, writing Java code to breach security can be easy. This chapter discusses some simple Java applets gone bad. Such applets are known on the Net as malicious applets. Entire collections are available for anyone interested to see, to adapt, and to use. See, for example:
Chapter... Preface -- 1 -- 2 -- 3 -- 4 -- 5 -- 6 -- 7 -- 8 -- 9 -- A -- B -- C -- Refs
Copyright ©1999 Gary McGraw and Edward Felten. |
