As we mentioned in the previous section, there are a number of Java security needs that third-party vendors can help to address. We discuss such needs here and also raise some hard questions that you should ask vendors of such products if you're considering buying them. Perhaps counterintuitively, some concerns included in this section are also covered in the next, which discusses risks that can't be easily addressed. That's because the issues are complicated and can be seen equally well from both points of view.
For a discussion of why logging is important, see page 194. The Java platform in most browsers does not do an adequate job of logging mobile code. This is an area in which third-party software can add real value. However, logging is actually trickier than it might appear at first blush.
If vendors say that their products log all incoming byte code, you should ask how they can be sure. This is roughly the same issue we describe next when we talk about applet isolation. After all, if code can slip past your firewall, how can you be sure it can't slip past the logging facility?
A common approach to security for many companies includes the installation of sacrificial lamb machines in a DMZ (terminology borrowed from military speak). Things like Web servers and FTP servers are well-situated in DMZs because they are common targets of attack with many well-known and commonly exploited security holes. The idea is to create a subnetwork behind the firewall but isolated from the rest of your network. That way, if the servers are hacked, your site is still not completely compromised. Isolating untrusted code to a server in the DMZ may be a good idea, depending on your mobile code risk analysis. If mobile code turns out to be hostile and aims an attack at the server it is running on, much less is lost if the server is a sacrificial lamb in the DMZ. Some third-party solutions offer this capability.
Another hard question for vendors involves the use of encrypted channels for mobile code delivery. Most browsers have built-in capability to create an SSL connection between the Web server and the client browser (see Chapter 3). Once an SSL connection exists, all traffic between the browser and the server is encrypted. That means a firewall will not be able to parse the traffic as it goes by. What a firewall can't see, it certainly can't identify. Ask vendors what they do about encrypted communication in their identification approach. If they can't scan SSL traffic, they're in trouble because an attacker can defeat their scanner by changing http to https in the attack page's URL.
The idea of creating a list of applets known to be hostile seems like a really good idea. The key is to identify hostile applets by something less easy to change than their name or the URL from which they came. Some systems use hashing algorithms like MD5 to create a database of applets on a black list. Others offer the ability to black list entire Web servers. Assuming applets can be identified in the first place, black listing will work. One problem is that it is almost trivial to make a hostile applet that changes its own byte code (in a very simple way) each time it is requested from a server. Mark LaDue's HAMGen applet does this. See http://www.rstcorp.com/hostile-applets/Rube/HAMGen.java. HAMGen stands for Hostile Applet Mutation Generator.
Nevertheless, black listing is so cheap to implement that it may make sense to do it anyway, especially if you enlist the help of a Class Loader. Using a system that blacklists known hostile code may be worthwhile even if it only stops the occasional naïve attack.
We discussed trusted dialogs and meters earlier in this chapter on page 198. Such dialogs are particularly useful to managers whose policy involves having users keep an eye out for unusual activity. They are also useful to more savvy users who know about mobile code. The problem with most VMs today is that they give no indication that anything special is happening when mobile code is running, be it Java, JavaScript, or ActiveX. The behind-the-scenes approach gives the user a more seamless Web experience, but it makes the job of writing a hostile piece of mobile code that much easier. There is a downside to providing dialogs and meters-the user can become overwhelmed with security-related dialogs leading to the "cry wolf" phenomenon. It's easy to click OK over and over, especially when you're annoyed. Trusted meters and dialogs would best be as nonintrusive as possible.
One of the most successful Java marketing phrases is "write once, run anywhere." A number of parodies of this phrase have been floated; among the best is "write once, test everywhere." The problem is that all Java VMs don't always do the same thing given the same byte code. Arbitrary behavior of similar code in different versions of a language is a problem that Java was supposed to solve. This problem can introduce real security risks. Consider, for example, that the attacks described in Chapter 5 still work against old versions of browsers out there. Unless you have an up-to-date browser, you may be surfing dangerously. Now imagine that you are the administrator for a large site with hundreds of users. How likely is it that all your users are using up-to-date browsers? How likely is it that they're even using browsers from a single vendor? Some sites address this problem by mandating the use of a particular (often out-dated) browser; however, impatient power users will download their own free browser and install it themselves. Using a move that mirrors the Applet Isolation idea discussed previously, it is possible to address this risk by forcing all applets to run on a central server. That way, you can guarantee things about the environment in which mobile code will run.
Note that the management issue is not unique to security. Managing large networks of many machines is a daunting task, and the tools are not yet good enough. Consider the problem of keeping all the software on hundreds of PCs up to date. To some extent this is a problem introduced by the complications of distributed systems. Security in merely one aspect of this broader management problem.
Chapter... Preface -- 1 -- 2 -- 3 -- 4 -- 5 -- 6 -- 7 -- 8 -- 9 -- A -- B -- C -- Refs
Copyright ©1999 Gary McGraw and Edward Felten. |
