t. These days, with Java applets everywhere and with millions of people using Java-enabled browsers, you need to know where you're pointing your browser.
The problem is that there is no pat solution here. The bad news: There are risks. The good news: Java's designers were well aware of these risks and did their best to limit them. For instance, the increased use of digital signatures (which authenticate code as coming from a trusted source) in JDK 1.1 helps with risk reduction.
Still, you
are
vulnerable, and for now there's not a lot you can do. Although Java marketing hype tends to ignore and gloss over the risks, you're better off knowing about them, even if there's little that you as a Java user can do except to limit your exposure to Java a
nd other forms of executable content (e.g., ActiveX, JavaScript, Safe-Tcl, and Telescript).
What potential problems does executable content raise? There are four basic categories: attacks that modify a system, attacks that invade a user's privacy, attacks that deny legitimate use of a machine by hogging resources, and attacks that antagonize a user. (See the table
"Four Classes of Attacks"
.) Keep in mind that this table only gives a flavor of the kinds of things that are possible and is by no means complete.
System Modification
A programming language as powerful as Java has the ability to modify data -- whether it's in a computer's memory or in the file system. Java includes predefined classes with methods that can delete and otherwise modify files, modify memory that's in use, and kill processes and threads. This power has the potential for abuse.
System-modification attacks make up the most critical risks. Java's designers have given much thought to
disallowing this class of attacks. In contrast, ActiveX has
no
limitations on its behavior once it's invoked.
In the most serious cases, system modification involves intrusion into the system itself. Java misuse can create an avenue of attack. Given that system crackers will use any tool available to compromise security (thus gaining entry and user privileges), Java's designers and implementers must ensure that Java does not provide new ports of entry into a machine. (Users can't do anything but be careful about their Java use.) And because Java works on many different platforms, a successful attack on, say, Solaris machines will also be successful on Windows NT machines. Never before have cross-platform attacks been such a distinct possibility.
The bad news is that using Java to break into a machine is certainly possible. Attack applets -- ones that implement system modifications -- have been demonstrated in the laboratory. Princeton University's Safe Internet Programming Team, which ha
s discovered many of Java's known security holes, has created attack applets that exploit these holes. Patches have been developed that make these attacks impossible, but the possibility of other sophisticated attacks always presents a risk.
With today's mission-critical computers, system-modification attacks could corrupt financial records in a seemingly secure database, leading to financial loss and corporate bankruptcy, or modify hospital patient records, possibly leading to incorrect treatment and even death. Care must be taken not to expose critical systems to new lines of attack. Since crackers flock to the latest and greatest vulnerabilities, it's important that Java not become a cracking tool.
Invasion of Privacy
A second general type of attack discloses confidential information about a user or a host machine. For example, in Unix, access to the
/etc/passwd
file (which contains user names and encrypted passwords) makes it possible to mount a password-cracking at
tack that can open a machine to attackers.
A system can also leak other sensitive information: Consider an unscrupulous company's being able to steal a competitor's secret business plan through corporate espionage. Individual users should consider whether they would want their private e-mail or financial records to be made public. Any confidential information that can be e-mailed or otherwise transferred over a network is subject to an invasion-of-privacy attack.
With Java, the standard mail-forging attack is much more serious because doubly forged e-mail is a possibility. The applet uses a patsy system to send fake messages, disguising its actual origin. (See the figure
"Doubly Forging E-Mail with an Applet"
.)
Finally, the sound capability present in many systems today opens up a new kind of eavesdropping. If an attacker can gain control of a system's microphone, it's possible for him or her to listen in on the area immediately surrounding the system. More subtle eaves
dropping includes monitoring process tables and file access. A Web-based version of eavesdropping might include keeping track of which links a particular user follows.
Java successfully defends against some of these types of attacks. For example, file I/O has especially tight controls. However, this is countered by the fact that applets always have a channel over which to send back information. That's because applets can always talk back to the server where they originated. Mail forging is harder to defend against. Short of disallowing contact to a client's ports, mail-forging attacks are not likely to go away.
Denial of Service
Denial-of-service attacks make system resources unavailable for legitimate purposes. They occur when a process siphons more than the standard allotment of resources, essentially hogging the machine. There are many subcategories of denial-of-service attacks. Some examples include completely filling a file system or using up all available file pointers; a
llocating all of a system's memory, creating thousands of windows -- effectively denying access to the output screen or to the window-event queue; and using all of a machine's CPU cycles by creating many high-priority threads. Although denial-of-service attacks are of real concern, Java's designers have not properly addressed them.
There is some debate over the relative importance of stopping denial-of-service attacks. In most cases, denial of service comes closer to the category of attacks that antagonize the user than to any other category. This is because recovering from a denial-of-service attack is usually easy: You just reboot the machine. Even so, denial of service for mission-critical computers can be serious; you certainly don't want to be rebooting crucial links in your system chain. For example, imagine the mayhem that would erupt if an applet clogged the machines that run the stock market: The resultant losses could be staggering.
Denial-of-service attacks are one of the most common Ja
va security concerns. For live examples, see Mark La Due's Hostile Applets Home Page at
http://www.math.gatech.edu/~mladue/HostileApplets.html
. Implementing such an attack is not hard; however, stopping one is, because the current Java security model does not offer a good solution to this problem.
Avoiding Hostile Applets
