| The Java security model is not perfect. Devious
developers can create Web-embedded Java programs, known as
hostile applets, that can make life miserable for Web
users. The good news is that JavaSoft's revamped security
model, which will evolve over the next year, may shore up
Java's current security weaknesses. Hostile applets divide into two groups: attack applets, which cause dangerous security breaches, and malicious applets, which are annoying rather than destructive. Although less harmful, malicious applets are insidious because you might load one on your machine simply by surfing to a Web page. What Applets Shouldn't Do Java's run-time processing enforces severe limitations on what applet-related classes can do. Applets, for example, cannot read or write to the disk. However, an attack applet still could corrupt data on your hard drive, reveal private data to third parties, infect your machine with a virus, or install a trapdoor to your machine. A cracker could attain his or her ultimate goal — complete control of your machine. To date, we know of eight serious security problems in Java implementations, ranging from Domain Naming System (DNS) name-resolution problems to type confusion. One serious flaw, discovered last August, was in Microsoft's implementation of how Java checked whether a class was allowed to be a member of a particular package. An attack applet could change security parameters and ultimately gain full access to the victim's files and network. This flaw in Microsoft Internet Explorer 3.0 Beta3 was fixed in Explorer 3.0. These attacks are not hypothetical. Every attack has been implemented by the Safe Internet Programming team at Princeton University (led by one of the authors) to break into a test machine in the lab. Our analysis demonstrated that attack applets require in-depth understanding of complicated Java and Internet issues to pull off. Nevertheless, it takes only one person to devise a novel attack applet; once loose, information about it would spread quickly throughout the cracker community. Even the lesser malicious applet can disrupt your local system and invade your privacy. Malicious applets written by miscreants currently can forge mail from you to anyone saying anything, steal your machine cycles to perform their own work while your processes languish, and crash your local system by sucking up system resources. There are also malicious applets created simply to annoy: Play sound files forever, monitor your Web use, and display unwanted graphics. New Model To fight hostile applets, JavaSoft will redo Java's security model over the next year (see the Core Tech article "Java Security and Type Safety" [not available on-line until the end of March 97]). The first enhancement will appear in JDK 1.1, due early this year. Signed applets would contain the creator's encrypted signature to help determine whether they can go beyond the "sandbox" — the secure browser partition where applets normally run. Trusted applets could read or write to local storage or access a uniform resource locator (URL) other than their own. Signing is not very robust. It doesn't stop applets from inflicting damage; it just tells you whom to blame. And it's all or nothing: You either trust a signed applet outside the sandbox or you don't. A better alternative allows finer control over a program. Later this year, you should be able to grant specific permissions to Java programs, choose a different security policy for each program, and even change policies on the fly. For example, you could keep applets in the sandbox unless they originate from a trusted site, or allow some applets to read from (but not write to) local storage devices. Will these improvements plug all possible security holes in Java? Even JavaSoft's security architect, Li Gong, says it probably won't. "We can't guarantee the security model 100 percent," he says, "[it's] how that model is implemented when it comes to writing the code." Security SiteApplets vs. Applications
†Applets and applications can offer users more versatile options based on signing, the code's point of origin, or the type of action the code is attempting to do. 
Gary McGraw and Edward Felten are authors of Java Security: Hostile Applets, Holes, and Antidotes (John Wiley & Sons, 1996). Tom R. Halfhill also contributed to this sidebar. Copyright 1994-1998 BYTE |