BUY IT!
Securing Java

Previous Page
Previous Page
Securing Java: Improvements, Solutions, and Snake Oil
CHAPTER SECTIONS: 1 / 2 / 3 / 4 / 5 / 6

Section 4 -- Risks That Third-Party Vendors Can Address

Next Page
Next Page

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.


Logging

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.


What to Ask about Logging
The main thing to ask of any logging capability is, how well protected is the log file from being overwritten, corrupted, or deleted? Attackers often cover their tracks by editing log files. Attack applets of the sort we discussed in Chapter 5 could certainly change logs if they wanted to. Accuracy is also a big issue for log files. It is important that logs collect proper data and can't be easily mislead by a malicious process.

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?


Applet Isolation (and Identification)

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.


What to Ask about Applet Isolation
One interesting question to ask vendors of isolation products is, how well do they identify applets in the first place? It turns out that trapping all applets is not an easy problem. Early approaches relying on scanning port 80 traffic for the <APPLET> tag have been shown to be inadequate (something we mentioned in 1996). One of the most thorough treatments of this issue can be found in a paper called Blocking Java Applets at the Firewall [Martin, et al., 1997]. The paper points out problems with standard blocking methods and discusses the technical difficulties of blocking.

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.


Black Listing

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.


What to Ask about Black Listing
It should be clear that black listing by itself does not provide adequate security; in fact, all by itself, black listing is darn close to useless. It's too easy to make trivial changes in a malicious applet (a process that can be automated at the Web server end) to thwart almost every black-listing scheme.

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.


Trusted Dialogs and Meters

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.


What to Ask about Trusted Dialogs and Meters
A particularly hard question to ask is, how can dialogs and meters avoid the spoofing problem? In other words, how can you be sure that the "meter" you see on the screen is real and isn't really being drawn by a hostile applet? If these things can't be trusted to tell you the truth, then they're not worth the pixels they're made of. Turns out this problem is a tough one. A nontrustworthy meter is potentially worse than no meter at all.


Platform Proliferation

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.


What to Ask about Centralized Server Solutions
A big issue for all centralized systems is scalability. How many users can bog down a central server before it chokes? How big a server do you need? What protocol is used to direct GUI traffic between the server and the clients running on normal browsers? How well protected is that protocol against simple denial-of-service attacks? And given the difficulties in detecting incoming applets, how can you be sure that all applets are being redirected to the central server?


Policy Management
Finally, we come around to policy management again. Given the state of existing tools, there should be some serious demand for good policy management systems.

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.


What to Ask about Policy Management
Policy management is as much a business management problem as it is a technological problem. Human factors enter the picture, such as, who is allowed to set policy and who can edit it? An excellent goal to strive for is to put in place a site-wide security policy that speaks to all security issues. Much work remains to be done.

Previous Page
Previous Page


Search Help
Next Page
Next Page


Menu Map -- Text links below

Chapter... Preface -- 1 -- 2 -- 3 -- 4 -- 5 -- 6 -- 7 -- 8 -- 9 -- A -- B -- C -- Refs
Front -- Contents -- Help

Copyright ©1999 Gary McGraw and Edward Felten.
All rights reserved.
Published by John Wiley & Sons, Inc.