Appendix C. Security Resources

Books are very useful for learning some things, and hopefully you've gotten some benefit from the one you're holding in your hand. However, for some types of information, the Internet remains the better choice. In this appendix, we'll list and discuss various network resources that relate to Java and security.

One reason why this information is better found on the Internet is because it is subject to rapid change. The APIs we've discussed may remain fairly stable (despite the big changes in many of them between 1.1 and 1.2[1]), but the information to be found in these resources is more dynamic.

[1]1.2 is now Java 2.

C.1. Security Bugs

Early in my computer science career, I handed in an exam that ended up receiving a lower grade than I had expected.[2] As part of the exam, I was asked to write an algorithm, prove that it was correct, and then provide an implementation of the algorithm.

[2]Okay, that was not an unusual event for me...

While my algorithm and its accompanying proof were completely correct, my implementation received a failing grade. This was a rather dispiriting result: I had come up with a solution and proved that the solution was correct. But the "real" solution--the implementation--was still flawed.

Such is the potential problem with implementing a security model. A lot of design and analysis has gone into Java's default security model, and hopefully you'll put your own effort into making your own applications secure. But no matter how sound the design of a security model, in the end it is the implementation that matters.

In this section, we'll discuss some past bugs in Java's security implementation and list some common resources for finding out about and fixing present bugs.

Few issues in the Java world receive more attention than security bugs; report of a new bug is guaranteed to produce a flurry of activity. As a result, readers of the trade press often have the idea that Java is riddled with security bugs, or that it isn't secure to begin with. This is not the case. While some important bugs in Java's security implementation have been reported, the impact of these bugs has (at least until now) been minimal.

Bugs that are reported against Java's security model fall into one of five categories:

Reports that are not bugs, but that arise from a lack of understanding of Java's security model

There are two types of very common bugs in this category: applets that perform annoying tasks, and applets that seem to break out of the sandbox. The former category includes applets that take lots of CPU time or otherwise consume many resources. As we mentioned at the outset of this book, such attacks are annoying but are not security attacks.

The latter category often involves bugs that hinge upon someone having installed a local class file (or worse, a local native library); as we know by now, these local class files are treated as trusted classes. When one of these local classes is able to read (or remove) files on your disk, contact a machine on your local network, or engage in some other potentially malicious behavior, word goes out that Java is not secure, or at best has bugs in its security model.

The lesson to learn from these reports is this: no computer security model is a substitute for vigilant 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 1.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 don't 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 we've 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 doesn't accept a particular construct that it should accept, for example, no security concerns arise.
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^TMand 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 about JavaScript are often confused with bugs about Java, in part because of the name. It is probably well known by this point, but it doesn't hurt to reiterate: JavaScript and Java are completely different technologies produced by separate companies (Netscape 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 it is able to serve HTML.
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 user's CLASSPATH is globally set to include those classes. Now untrusted classes will be able to access the third-party classes.
Bugs in the Java implementation

There have been several well-publicized bugs that do involve Java's security implementation; as with any large computer system, there are bound to be others.

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 that 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.

C.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 all these bugs have been fairly minor and quickly fixed is of some comfort. That is not to say that a future bug won't be more devastating or harder to fix; the point here is really to shed light on the bugs that have been found.

The bugs we'll 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.

Here's a chronology of security bugs that have been found in Java through November 1998. There was an additional bug reported in July 1998 regarding the class loader, but this applied only to Netscape's 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 above 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 user's 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 user's machine be running in a DNS domain that it was not registered to and that the attacker's machine be running in that same DNS domain. This bug was fixed in 1.0.2.
Class loader bug: In May 1996, a bug in the class loader was discovered that allowed two applets loaded in different class loaders to exploit a way of casting between different classes with the same distinct name. This bug was fixed in 1.1.
Verifier implementation bug: In March 1997, Sun discovered a bug in the implementation of the verifier. Exploiting this bug would have required knowledge of the bug itself as well as writing Java bytecodes by hand. This bug was fixed in 1.1.1.
Class signing bug: A bug in the getSigners() method of the Class class was discovered in April 1997. This bug allowed code signed by one entity to be treated as if were signed by a different entity (possibly with more access to the user's machine). This bug was fixed in 1.1.2.
Verifier implementation bug: A bug that could allow the VM to crash in the bytecode verifier was discovered in May 1997; this bug was fixed in 1.1.2.
Illegal type casting: A bug related to illegal type casting was reported in June 1996. This bug allowed an applet to undermine the typing system of Java. This bug was fixed in 1.1.3.

C.1.2. Tracking Security Bugs

The nature of tracking security bugs makes it impossible to track them through a book such as this; we're sure that the above list is already out of date. Hence, the better way to track security issues with Java's implementation is to check periodically the following resources on the Web.

An important point to realize about these sites and the bugs we've just listed is that much of the research on security implementation bugs occurs outside of Sun. Sun's approach to Java security is to achieve security by openness--that is, the more people who can examine the platform for implementation bugs, the better that implementation will become. This is one reason why the JDK source code is freely available for noncommercial purposes.

http://java.sun.com/sfaq/chronology.html

This page lists the known bugs in the security implementation (the above list was culled from this page). New bugs and their fixes are reported here first.

http://www.cert.org/

The CERT organization tracks security-related bugs for all types of computer systems, including Java implementations. Java-related security bugs are often published as CERT advisories.

http://www.cs.princeton.edu/sip/

Many of the bugs in Java's security implementation have been discovered as a result of work done at Princeton's Security Internet Programming (SIP) group. This page summarizes their work, including several of the bugs that were listed above.

Work at SIP is funded by many companies, including Sun itself.

news://comp.security.announce

This newsgroup tracks security-related announcements about all systems, including Java.

http://kimera.cs.washington.edu/

This research group is also responsible for finding some of the bugs that were listed above.

http://www.alw.nih.gov/Security/security-advisories.html

This site has links to several services that publish advisories when Java (and other) security-related bugs are discovered.

Appendix C. Security Resources

Contents:

C.1. Security Bugs

C.1.1. Java Security Bugs

C.1.2. Tracking Security Bugs