This week we're going to finish beating to death the issues of security, Java, and the Web. We'll also point out a few things about where the lines of applet security are drawn, which you may have heard before but cannot be pointed out enough. Hopefully, we'll also be able to avoid drawing lurid parallels between the societal dangers of promiscuous exchange of code and promiscuous sex. Journalistic integrity is not easy to come by, let us assure you. Security
Last week we talked a bit about the nature of the security problem, but gave more factual information regarding the low and mid-level security of the Java system. Romanticism aside, the obscure and arcane ways in which it may be possible to trick the Java Virtual Machine into allowing a direct, low-level security violation are really less important. The crux of security will always end up lying in the place where we cannot tell a malicious program from a benign one.
The problem is that, at some point, it's always possible for an application program within a modern operating system to use whatever tools it may be given, in order to be useful as well as harmful to yourself and/or your computer. If you give a program the ability to use RAM or hard drive space, it can use all of it, blocking other programs from needed resources. If you give a program the ability to read or write things on your screen, it can fill your screen with garbage, or perhaps cause it to lock up. Or, more creatively, the program might try to trick you by pretending to be another program, or part of the operating system, in order to steal a password, for instance.
In other words, your computer is not fundamentally designed for security. At a basic level, computers were originally designed to be single-task machines, with no concept of ownership, privacy, or boundaries. Almost all, except for the most experimental, still start from this point. From there, many operating systems have arrangements in their own internal resource-sharing systems that attempt to protect the operating system from a malfunctioning program, or users from each other, but hardly ever to protect a user from his or her own programs. Understandably, until recently, for the average computer user any code likely to reach his or her computer was probably coming from an identifiable, supposedly trusted source--floppy disks.
Recall last week when we mentioned the "login spoof" attack. A program can convincingly imitate a legitimate request for a user's password, and thus compromise security. We said that Java designers had addressed the issue of these kinds of imitation by making sure (hopefully) that all windows created on the screen by Java are tagged with a highly visible "Untrusted Java Applet Window" marker, which is a good first step. But put yourself in the place of an evil applet designer: What can you do to get around a warning tag on the bottom of your windows? A common solution to this problem, which can be observed along with a number of other hostile and dangerous applets on this page, is to simply make the window in question larger than the user's screen size, since we can control the size of our windows. Most windowing environments thus far simply let the warning slip off the bottom of the screen.
Along with this hostility (which can be doubly annoying for users of some operating systems in which it may be impossible to regain control of their screen once a gigantic window is coverting everything), there are applets that endlessly produce annoying noises, or take advantage of the many ways in which a Java applet can make Netscape crash. Recall a past column in which we pointed out that Java applets do not stop running when you leave the Web page that caused them to load. They must be designed so that their
stop()methods cease activity, which isn't sensible after they are no longer being viewed. It's a requirement of good applet design that applets stop running when no longer necessary, and many of these applets do just the opposite, running constantly after you've unsuspectingly loaded them from a Web page.All of these concerns aside, there are also places where the designers of Java made arbitrary decisions that some have since found questionable regarding boundaries of security and isolation. The best example of this is one where Java System Properties may give away some things you may not have expected to be advertising to people whose Web pages you view.
Quickly consulting the list of properties available to applets handily provided by Sun, you'll find that your architecture and operating system information are available (although this is hardly shocking since most browsers give that away by sending USER_AGENT information anyway). But one additional compromise that many people are still surprised by is the fact that, in theory, your current working directory, your "home" directory, and your username are also available to the applet. Although these concepts have varying relevance from one operating system to the next, their availability to the applet designer is significant.
We wrote a quick applet to show you what your computer was giving away. We found at the time of this writing, both Netscape 3.0 and the Sun Appletviewer (for Solaris, at least), in spite of the assertions of the Sun documentation, do generate a security exception when this applet runs. Your mileage may vary. Hopefully, what you see below is a message telling you that your SecurityManager is protecting you. If not, you've been forewarned and be thankful we're not collecting e-mail addresses to send to e-mail direct marketers.
As much fun as it would be to continue to demonstrate the awesome power you've given us--the applet designers--over your computer, the best work in this field has already been done, and we encourage you to (very cautiously) check it out. Just be careful out there.
Also noted in Sun Denial of Service Page: Web Graffiti
