As we have mentioned, Java is not the only game in town when it comes to mobile code. Other mobile code systems include JavaScript, Safe-Tcl, Telescript, Word macros, Excel macros, ActiveX, and Postscript. Of these systems, the one most often touted as a direct competitor to Java is Microsoft's ActiveX (sometimes called DNA depending on the whim of Microsoft marketeers). So what does ActiveX do for security, and how does it compare with Java's approach? Besides ActiveX, what other mobile code systems present security risks?
The first thing to know about ActiveX is that it does not have an enforcement-related security model. It has a trust model that may be able to help you implement your own security policy. So the real question is: How does a trust model like ActiveX's compare with a sandbox like Java's?
The second approach, code signing, is how the ActiveX Authenticode system works. Binary files, such as ActiveX controls or Java class files, can be digitally signed by someone who "vouches" for the code. If you know and trust that person or organization, you may choose to trust the code that they vouch for. It is important to stress the fact that code signing is completely a matter of trust; there is no enforcement mechanism protecting you once you decide to trust a piece of code. The trust model implements authentication and authorization. What this means is that there is no such thing as ActiveX security enforcement! That's not to say signature-based trust models are not useful. They are. In fact, trust models will play an integral role in future security models for mobile code. Much more detail on code signing, especially as it relates to Java, is found in Chapter 3, "Beyond The Sandbox: Signed Code and Java 2."
One caveat: Comparing ActiveX and Java is somewhat like comparing apples and oranges, even though everyone does it. ActiveX is a component-based software model while Java is a language/platform. ActiveX should really be compared with Java components, JavaBeans. (In fact, some argue that the real religious Holy War between Java and ActiveX is destined to take place in the middleware arena and will be decided by the battle of component models [Lewis, 1998].) ActiveX has been roundly criticized by computer security professionals since its approach to security is seen as lacking. Unlike the base Java security situation, in which an applet has to run in the sandbox and is limited in the sorts of things it can do, an ActiveX control has no limitations on its behavior once it is invoked. The upshot is that users of ActiveX must be very careful only to run completely trusted code. On the other hand, Java users have the luxury of running untrusted code fairly safely. The ActiveX approach relies on digital signatures, a kind of encryption technology in which arbitrary binary files can be "signed" by a developer, distributor, or certifier. Because a digital signature has special mathematical properties, it is very difficult to forge. That means a program like your browser can verify a signature, allowing you to be fairly certain who vouched for a piece of code (as long as people are carefully guarding and managing the private keys used to sign code). To make things easy, you can instruct your browser always to accept code signed by some party that you trust, or always to reject code signed by some party that you don't trust. The signature also supplies data integrity, meaning it can ensure that the code you received is the same as the code that was originally signed. Signed code cannot be easily hijacked and modified into a Trojan Horse. The ActiveX system provides a black-and-white trust model: Either you trust the code completely and allow it to run unhampered on your machine, or you don't. That means trusting the wrong sort of code just once is all it takes. Once an attack control runs on your system, it can rewrite your security policy in such a way that all future attacks will work. Of course, it can do anything at all, so this is only one of zillions of attack scenarios. Serious attacks using ActiveX have been seen in the wild (although their use is not widespread). For an explanation of these attacks and more on ActiveX insecurity, see Anup Ghosh's book E-Commerce Security: Weak Links, Best Defenses [Ghosh, 1998].
Another significant factor is that the sandbox approach is more robust in the face of accidental bugs in mobile programs. Even if the sandbox isn't bulletproof, it will most likely prevent a bug in a mobile program from trouncing important data or programs by mistake. As we shall see in Chapter 3, when combined with access control, code signing allows applets to step outside the security sandbox gradually. In fact, the entire meaning of sandbox becomes a bit vague. As an example of how Java code-signing might work, an applet designed for use in an Intranet setting could be allowed to read and write to a particular company database as long as it was signed by the system administrator. Such a relaxation of the security model is important for developers who are chomping at the bit for their applets to do more. Writing code that works within the tight restrictions of the sandbox is a pain, and the original sandbox is very restrictive.
Microsoft Internet Explorer 4.x implements a security zone concept meant to ease the management of security policies for signed content such as ActiveX controls and Java applets. The system organizes Web sites into four "zones of trust" (or more if you customize): Local intranet zone, Trusted sites zone, Internet zone, and Restricted sites zone. Each zone can be configured with security levels of: High (most secure), Medium (more secure), Low, or Custom. The idea is to divide Web sites into these zones and assign the zones varying levels of trust. Figure 1.7 shows a dialog box from Microsoft Internet Explorer (MSIE) that allows a user to manage Authenticode security zones.
Zones are a useful tool that can help make a security policy more coherent. The concept may be particularly useful in non black-and-white policy situations currently beyond the scope of ActiveX. We think security zones are a useful tool that Java security systems beyond Microsoft's should support as well. In ActiveX with security zones, the security policy itself remains black and white: A mobile program is either fully privileged or completely banned from the system. Since most users are inclined to run cool-sounding code just to check it out regardless of the risk, popping a dialog box in front of a user and requiring an instant security decision is not a good idea. As one of the authors (Felten) is known to say, "Given a choice between dancing pigs and security, users will pick dancing pigs every time." The Princeton team correctly warns that relying completely on a human-judgment-based approach to security in not likely to be as successful as blending judgment with technology-based enforcement, as newer Java systems do. See Figure 1.8.
One way in which Authenticode addresses this problem is to put the security decisions in the hands of a system administrator. Using the MSIE Administration Kit (IEAK), an administrator can preinstall a list of permitted certificates and block the installation of others. This is a step toward centralizing security policy management (which is something most corporate users demand). However, in the end, the ActiveX model is still only a trust model. Just for the record, Netscape now includes a similar site-wide policy administration system. We discuss these issues of trust, identity, and signatures again in more detail in Chapter 3, though the focus is on Java and not ActiveX.
Two other good places to look are in Chapter 2 of E-Commerce Security by Anup Ghosh [Ghosh, 1998] and page 18 of Web Security Sourcebook by Avi Rubin, Dan Geer, and Marcus Ranum [Rubin, Geer, and Ranum, 1997].
Another mobile code system is JavaScript (Microsoft's version is called JScript). Note that other than the four letters-J, A, V, and A-JavaScript has nothing in common with Java. In the early days, JavaScript was known as LiveConnect, but once the marketing folks at Netscape saw the Java wave building, they decided to ride along. JavaScript allows code to be directly contained in HTML documents themselves, code that can dynamically change the HTML that a Web user ultimately sees through a browser. JavaScript has its own security headaches. Though it is not an ultra-powerful scripting language, JavaScript can easily be used to carry out denial of service and invasion of privacy attacks. Much more discussion about denial of service is found in Chapter 2. JavaScript was used extensively in the Princeton Team's Web Spoofing attack [Felten, et. al., 1997]. To find out more about JavaScript security, a good place to start is at John LoVerso's JavaScript security site: www.camb.opengroup.org/~loverso/javascript/. On his JavaScript Problems I've Discovered page, LoVerso describes JavaScript attacks that:
The important take-home message of this section is that Java security concerns do not exist in a vacuum. If someone tells you that you should disable Java, but pays no attention to these other threats, he or she is not doing you much of a favor. The truth is, much scarier things than Java are out there. In fact, many of the attacks we have touched on here pale in comparison to security concerns raised by a Windows 95 PC connected to the Internet. Try to put all of the security concerns relevant to you on the same scale, and address the biggest risks first.
Chapter... Preface -- 1 -- 2 -- 3 -- 4 -- 5 -- 6 -- 7 -- 8 -- 9 -- A -- B -- C -- Refs
Copyright ©1999 Gary McGraw and Edward Felten. |
