Groups and Roles Advanced JAAS Topics

practices by the end user. If your policy is never to run shareware programs downloaded from the Internet, then your policy should be never to install local classes on your system. And while newer versions of browsers, along with the ability in Java 2 to run applications in a secure environment, help to mitigate the potential danger of installing a local class file, such features will never obviate the need for users and system administrators to understand and work with the security model. There may be real bugs in the Java implementation −− but dont assume that all reports you hear about the sandbox being broken fall into that category. Bugs that are misclassified; that is, actual bugs that are reported as being security bugs when they are not. As weve seen, security is pervasive in the Java platform −− the bytecode verifier, the class loader, the security manager, and the compiler all have aspects of security to them. Hence, bugs in these areas are often considered security bugs even when they are not. For example, a bug in the bytecode verifier is usually assumed to be a security bug, even if it is not; if the verifier doesnt accept a particular construct that it should accept, for example, no security concerns arise. 2. Web−related bugs that are not Java−specific. Often, security problems on the Internet are associated with Java without any direct cause. In particular, bugs related to JavaScript TM and to ActiveX often fall into this category. When the first reports of ActiveX security bugs were circulated, there was a lot of discussion about active content; the assertion in many quarters was that the security problems that plagued ActiveX were inherent in any active content system. This assertion attempted to place Java in the same light as ActiveX since both were active content systems. The reality is that Java and ActiveX have very different security models. Similarly, bugs in JavaScript are often confused with bugs in Java, in part because of the name. It is probably well known by this point, but it doesnt hurt to reiterate: JavaScript and Java are completely different technologies produced by separate companies AOL and Sun, respectively. The two technologies are complementary in many ways, but they are fundamentally different from a security perspective. Finally, Java is not immune to security problems that plague the Web in general. Data that is sent between sites among Java applets and servers can be snooped just like data that is sent via HTTP can be snooped unless the Java traffic is using SSL or another encryption technique. A hacker that sets up a site to impersonate XYZ.com will be able to serve Java applets just as she is able to serve HTML. 3. Bugs in third−party trusted classes. When you install third−party classes, it is possible that one of them may breach the security model that you think is in place: it may provide a mechanism for an untrusted class to open a file, for example, based upon the permissions normally given to the third−party class. Complicating this factor is the manner in which these classes are often installed: they are often put into a directory and the users classpath is globally set to include those classes. Now untrusted classes will be able to access the third−party classes. 4. Bugs in the Java implementation. There have been several well−publicized bugs that do involve Javas security implementation; and as with any large computer system, there are bound to be others. 5. This last point should not minimized −− there have been and will be bugs in the Java security implementation. But the potential for bugs and their potential impact must be weighed against the potential benefits of using Java. I know of one corporation where Java is not allowed to be used for any internal project. This site is not worried about employees doing malicious things to other employees, and they filter out Java class files at their corporate firewall, but developers at this company are still not permitted to use Java for any internal project due to security concerns. When I asked about this policy, I was told this corporation had zero−tolerance for security problems, and the mere risk of a Java security bug was enough for them to forbid the use of Java. Of course, this site that had zero−tolerance for security problems had a floppy disk drive on every one of their desktop computers, and users routinely took files to and from the office via floppy disks. The potential for a virus being spread by floppy disk drive which is very real was outweighed for them by the benefit of their users doing work at home. Meanwhile, the thought that Java would somehow spontaneously corrupt their isolated network was, for them, enough to outweigh any of the potential benefits they saw to using Java within their extremely distributed, heterogeneous network. Assessing the security of a platform always involves assessing the potential risks and the potential rewards, though apparently that is sometimes hard to do. B.1.1 Java Security Bugs One of the ways to assess the potential impact of Java security bugs is to understand the bugs that have occurred to date and their relative impact. The fact that these bugs have been fairly minor and quickly fixed is of some comfort. That is not to say that a future bug wont be more devastating or harder to fix; the point here is really to shed light on the type of bugs that have been found. Most of the bugs well discuss in this section all have another property: attacks based on these bugs were very hard to construct. In fact, attacks based on these bugs never made it out onto the Internet or other networks; the bugs were all reported by various researchers, and often even the researchers had difficulty in constructing an attack against them. One bug in this list the Brown Orifice bug is an exception to that: it was fairly easy to exploit that particular bug long since fixed, of course. Heres a chronology of security bugs that have been found in Java through February 2001. There was an additional bug reported in July 1998 regarding the class loader, but this applied only to Netscapes implementation, not to the standard JDK. DNS spoofing In February 1996, the first Java security bug was posted. It involved a DNS spoofing scenario in which an applet could make a connection to a third−party host other than the one from which it was loaded. Such an attack required access by the attacker to a DNS server that was used by the user and knowledge of the IP address of the third−party machine. DNS spoofing is a general problem i.e., this bug falls into category 3 in our list, but Java was fixed in 1.0.1 to circumvent this scenario. Class loader implementation bug In March 1996, a bug was found that allowed an applet to load a class referenced by an absolute pathname. This bug was fixed in 1.0.1. Verifier implementation bug In March 1996, a bug was discovered that took advantage of an implementation error in the bytecode verifier. An attack via this bug needed to be very sophisticated, but it did allow the applet to perform any operation delete a file, write a file, etc. on the users machine. This bug was fixed in 1.0.2. URL name resolution attack In April 1996, a bug related to an obscure network configuration was reported. This bug required that the users machine be running in a DNS domain that it was not registered to and that the attackers Appendix B. Security Resources