Sun Microsystems and the licensees of Java who have created particular Virtual Machines have done an admirable job implementing a complex, language-based security model. Of course no one is perfect. We discuss several serious problems in detail in Chapter 5. In light of the problems detailed there (a majority of which have been addressed as Java has grown up), is there a need for third-party Java security vendors? The answer is complicated. On one hand, if Sun and the other major vendors (including the largest software organizations on the planet) can't do it right, how can someone else? One answer is that Sun is too busy working on the entire Java platform to pay enough attention to security concerns and that little companies specializing in security can do better. Just for the record, we don't believe that is true. Sun and the other Java vendors behave in a manner that shows they are truly concerned with security issues. On the other hand, different organizations have different goals for their security solutions. Some may demand features that are not included in off-the-shelf Java VMs. The implication is that special-purpose solutions that address particular risks are needed. If that's true, there should be plenty of room in the market for third-party security vendors to get involved. As long as such third-party vendors concentrate on mitigating particular risks, their products will add value. However, many such vendors are making overblown claims about what they can do to enhance security. In this section, we want to clarify which risks can reasonably be addressed by these vendors and which cannot. In order to set the stage for a discussion of risks, we'll begin with a brief introduction to security solutions that have been offered by third-party organizations.
In the interest of full disclosure, we should note that both authors are members of Finjan's Technical Advisory Board. Our membership on Finjan's TAB does not constitute an endorsement of the company or its products. Originally based in Israel and now headquartered in California, Finjan Software, Ltd. was among the first third-party companies to address mobile code security issues (www.finjan.com). Finjan got off to a rough start when some of its early marketing involved the use of scare tactics and what might be called the "Chicken Little" approach to educating the public (and potential clients) about security risks. Its approach to marketing has since matured significantly. Finjan offers a couple of products created for both Win32 and Unix platforms. The first, SurfinShield, is meant to be a browser-level application firewall. The idea is to add some capabilities to the browser to help with mobile code management. SurfinShield comes in several flavors. The second product, SurfinGate, is a firewall product that attempts to identify and categorize mobile code as it arrives at the firewall. SurfinGate carries out some form of content inspection that attempts to peer into the inner workings of Java applets (statically). SurfinCheck is a less-powerful version of SurfinGate. Finjan has had an interesting time in the mobile code security space and has been the target of some particularly scathing criticism. Mark LaDue is especially outspoken about his concerns (see www.rstcorp.com/hostile-applets/rube.html and www.rstcorp.com/hostile-applets/drowning.html). Fortunately, Finjan has taken these criticisms to heart and seems to be working diligently to provide better security products to its customers.
Digitivity, the commercial arm of APM, Ltd. in Cambridge, England, was recently acquired by Citrix. The Digitivity approach to mobile code management is particularly sound from a technical perspective. The idea is to identify and route all mobile code to a central server, where it is then executed. This works because all GUI traffic is sent (by specialized protocol) to be displayed on the client browser that originally requested the code. There are two main reasons to centralize the execution of code like this: 1) to expose only the server, what Digitivity calls the CAGE, to possible attack; and 2) to better manage the behavior of mobile code by knowing the exact configuration of the mobile code platform. As we know, different Java VMs behave differently even when they are running the same byte code. If you know for certain which VM a piece of code will run on, it is easier to develop and manage custom enterprise solutions. There is an inescapable irony to the Digitivity CAGE model. The very idea that spawned mobile code systems like Java is the idea of taking advantage of distributed systems by running code on client machines instead of running code on something like a centralized Web server. The CAGE model centralizes Java code and works counter to the original Java concept. Still, there are sometimes appealing reasons to centralize the execution of code, whether it is potentially dangerous or not. It is not clear how the CAGE approach will adapt to the new Java 2 security model. The main strength of the CAGE approach is that the mobile code runs on a special machine that simply is not allowed to access user files or initiate network connections under any circumstances. As soon as partially privileged applets enter the picture, this simple approach goes out the window and the CAGE machine faces many of the same problems as existing VMs.
Security7 is an Israeli company with offices in the United States. U.S. sales for Security7 are based in Woburn, Massachusetts. The Security7 approach to mobile code security is to inspect HTTP traffic coming in on all ports. Its SafeGate product requires Windows NT and is most effectively implemented on a standalone box that acts as a proxy server for all HTTP traffic. The idea is to enhance the existing firewall approach with the HTTP filtering system, which is built in to the OS as a device driver. The SafeGate product includes the usual mobile code management capabilities and logging. It appears that Security7 has been active in spreading FUD (fear, uncertainty, and doubt) among potential customers through an organization called WithinReach. This strategy is reminiscent of the early days of the antivirus industry in which some unscrupulous vendors were rumored to have created and released actual viruses. These days, a code of ethics has been developed within the antivirus community that does not permit the FUD strategy. Unscrupulous antivirus vendors are quickly stamped out by more scrupulous vendors. It is pretty obvious that Security7 and WithinReach are closely affiliated (in fact, Security7 has openly admitted this). Assaf Arkin, a Security7 customer support manager, is also the administrative and technical contact listed in the DNS records of WithinReach. Other evidence includes the fact that one of the hostile applets hosted by WithinReach was signed with a digital certificate registered to Richard Kosinski, Security7's vice president of marketing. The signature has since been changed. InfoWorld broke a story about the relationship between Security7 and WithinReach in late August 1998. Until recently, the WithinReach site hosted a number of hostile applets, including a port of the Cult of the Dead Cow's famous Back Orifice loader to Java. None of the applets on the site exploits any security holes in Java; instead, the applets require permission to be granted by the user in order to do anything harmful. That is, the applets are signed and request special permission to step outside of the sandbox. The applets thus serve to emphasize the role that a human can play in mobile code security. In this sense, the WithinReach applets may provide an interesting service. Nevertheless, we do not believe that it is ethical for third-party security vendors to create security problems for their products to address. Fortunately, Security7 seems to share our opinion now, and the WithinReach Hostiles have been removed.
eSafe is a Seattle-based company that also happens to be founded by an Israeli. eSafe offers two products: Protect, a personal firewall, and Protect Gateway, a firewall-level filtering system. Protect works by placing resource limitations on mobile code. The idea is to create a sandbox similar to the Java sandbox within which all mobile code must run. The Protect Gateway product is a filter meant to be added to an existing firewall that scans several protocols for mobile code. The filter includes blacklisting capability. eSafe products also include antivirus capability in addition to addressing mobile code security.
The Princeton team distributes a black-listing/white-listing Class Loader for JDK 1.0.2 that can automatically allow or disallow applets to be loaded from particular sites. The filter replaces Java's normal AppletClassLoader with a new implementation that checks URLs and policy before fetching code. Although this is not a commercial product, it is certainly a third-party add-on that some organizations may find useful. See www.cs.princeton.edu/sip/JavaFilter for more information.
Regardless of its misleading name, the International Computer Security Association is a for-profit business that licenses the use of trademarked "certification" logos. (Perhaps its name is a perfect example of spoofing?!) ICSA was known as NCSA until 1998 when it changed its name from "National" to "International." As part of its business, ICSA creates consortia of security vendors interested in particular issues. The consortia exist to hash out self-imposed certification criteria that can be used as a marketing edge by vendors. ICSA's business strategy is to get vendors to pay to be in a consortium (in which vendors create certification criteria) and then pay to be certified on a subscription basis. Consumer purchasing decisions are often swayed, for whatever reason, by ICSA certification marks. One of ICSA's best-known certification products involves certifying firewalls. The firewall certification system makes an interesting case study. As we understand it, ICSA's firewall certification process boils down to running a penetration test against one instance of a firewall product as configured according to printed instructions from the firewall vendor. If a firewall product passes the tests, the vendor is allowed to place an ICSA certification stamp on its box (and use it in its marketing literature). A potentially fatal flaw in this firewall certification scheme is that firewalls are not really black-box systems; instead, they are programmable systems that are only as strong as the rules within them defining security policy. Rules in a typical firewall say things like "only allow machines having an IP address within the proper range to send HTTP traffic through port 80." The flaw in the ICSA certification scheme becomes obvious considering that what is being certified is a particular configuration of a firewall. The problem is that firewalls are particularly easy to misconfigure, and the certification scheme says nothing about how difficult it is for an end user of a firewall to configure it correctly. Firewall purchasers may be misled into thinking that buying an ICSA-certified firewall guarantees some minimum level of security. That is not the case. For a stark view of the ICSA firewall certification process, see firewall guru Marcus Ranum's page at www.clark.net/pub/mjr/pubs/fwtest/index.htm. On the flip side of the coin, the firewall certification process that ICSA offers is said to be a discriminator; that is, some firewall products are unable to pass the security tests even when configured according to the instructions! So the certification has at least that benefit to offer. We raise the firewall certification issue because ICSA recently announced the formation of a consortium meant to address mobile code security. Current members of the consortium include Digitivity, eSafe, Finjan, Internet Security Systems, Security7, and Symantec (among others). Strikingly, the major vendors of security-critical platforms for mobile code (Sun, Netscape, and Microsoft) are missing from the list. The question raised earlier in this chapter about what third-party vendors can offer (as opposed to the platform architects) comes to mind. It is likely that the mobile code consortium will choose to invent a set of self-imposed standards (a certification process) for itself. The question to ask is, what will this certification amount to? Developing a certification standard for the mobile code consortium is no easy task if it is to be done properly. Without external review by experts, a mobile code security certification may not actually mean anything. It is our hope that ICSA will take the opportunity to do things right.
Chapter... Preface -- 1 -- 2 -- 3 -- 4 -- 5 -- 6 -- 7 -- 8 -- 9 -- A -- B -- C -- Refs
Copyright ©1999 Gary McGraw and Edward Felten. |
