Mobile
Code and Security Mobile code is code that traverses a network during its lifetime and executes at the destination machine. In its most powerful guise, the same piece of mobile code is able to run on multiple platforms (both Unix boxes and Win32 machines, for example). This powerful idea opens up many new possibilities on the World Wide Web, a heterogeneous collection of machines. For the first time it is possible to have Web-based programs whose behavior is coded in some common programming language. This code need not be compiled to tens of platforms and distributed only after determining the target platform. Instead, mobile code is written once and then runs wherever it ends up. There are many well-known systems for creating and using mobile code, including Java, JavaScript, VBScript, ActiveX, Postscript, and Word macros. See also the sidebar Where to learn more about mobile code security Become
a subscriber, and you'll get access A
Brief History of In the early days of the Internet, everyone agreed that downloading arbitrary binaries and executing them on your machine was a Bad Idea. Of course, most people did it anyway, and some people suffered as a result. By the mid 1980s, there was a lot of freeware and shareware available to download. To find it, you could use Archie, which provided a way to search a large index of anonymous FTP content. Once you found some leads (often several ASCII pages worth), you chose your target and FTP'd what you needed. Then you installed and ran it. The risks of downloading and running a random person's code on your machine are clear. If the code has a virus attached, it can infect your machine. If the program is a Trojan Horse, it can take over your machine for its own purposes while appearing to do something useful. How can we be sure that a program someone says is useful hasn't been hijacked to do something nasty? By the late 1980s, checksumming provided part of the answer. A checksum is a simple computation performed on a piece of code to provide a digest or a "thumbprint" of the code using a one-way hash function. At least a few anonymously downloadable programs included checksum data that could be used for rudimentary data integrity purposes, helping to ensure that the code downloaded at the end of the communication pipe was the same as the original code distributed by its author. Of course, who was to say that a program's checksum hadn't been tampered with or that an author did not include Trojan Horse functionality? You can make gaffes developing security-critical code in any language. This extra risk is not very alarming if we operate under the assumption that the code we're running is trusted. But why should a Web user trust a random piece of code encountered on the Web? Clearly they should not. As a reaction to this concern, many popular forms of mobile code (including Java) were designed to run untrusted code (and, more recently, partially trusted code) in a secure manner. This issue discusses how mobile code systems attempt to do this and to what extent they succeed. Developer Concerns From a technology perspective, a complete security solution for mobile code will always involve two distinct parts. First, the mobile code platform itself must be secure. For example, unless the Java Virtual Machine is doing its job perfectly, Java's language-based approach to security will not work.1 Second, any code developed for use on the mobile code platform must be designed and implemented with security in mind. In other words, simply writing code in Java is no guarantee of secure behavior. Obviously, developers play a critical role in both parts of the solution. Creating a mobile code system is a complex undertaking that pushes the limits of available technology and research. Consider Java. Sun Microsystems and the Java licensees have worked hard to evolve a system that supports secure creation and use of mobile code. But Java is not immune to security risks.1,2 Implementing a language-based security model is not easy, and there are bound to be mistakes. A prime example of the ways in which Java is pushing the envelope is its combination of type safety and dynamic loading. Java bases its security approach on type safety. Programs must be prevented from accessing memory and other security-critical resources in inappropriate ways. Every piece of memory is part of some Java object, including the classes that make up the security model itself. Java is also designed so that classes can be dynamically added and removed from the runtime environment. Dynamic loading is handled by Java's class loading mechanisms. The question is how to sustain type safety and allow dynamic loading at the same time. This complex question has been addressed in a recent dissertation.3 Many open research issues remain. Programming language researchers have also done some work trying to prove the soundness of the Java language and VM definition.4,5 Although this work is still in preliminary stages, some interesting and suggestive results are available. The bottom line is that the definition of Java will probably turn out to be sound, once many more details have been filled in. Developers are charged with creating secure implementations of both the mobile code platform and the code that eventually runs on the platform. Both of these tasks require a developer to navigate the often uncharted waters of language-based security. A necessary side effect of implementing mobile code (which can in some ways be considered a very large security-related experiment) is making mistakes and learning from them. What once required a conscious decision and a process now requires only a mouse click. Developing secure programs in any language is neither trivial nor automatic. Anybody who reads the newspapers or the trade press can see how often skilled programmers write code with security bugs. You can make gaffes developing security-critical code in any language. Know your enemy. Think about what might confront your code in terms of malicious attacks. Mitigate risks by designing, coding, and testing carefully. The Articles Through a peer-review process, we selected four articles that touch on the central issues of mobile code security. Two of them provide broad views of this domain.
The third and fourth articles describe models related to securing Java code and code written in Web scripting languages.
Can Mobile Code be Secure? Today's diverse approaches to securing mobile code are all works in progress. Each different implementation of mobile code, including Java, ActiveX, and JavaScript, faces similar security risks; but each system presents a different way of dealing with the risks. In our opinion, Java's security design stands head and shoulders above the competition. But Java is a complex system that is evolving at a serious clip. Securing Java and other forms of mobile code is still as much an art as it is a science. There is no such thing as absolute security, whether the code is mobile or stays put right where it is developed. Creating and maintaining secure systems requires rigorous software assurance and the ability to manage risks wisely. Mobile code makes securing a system more complicated, but the benefits of mobile code are often worth a bit of added risk. As the world becomes increasingly networked and interdevice communication becomes essential, mobile code is likely to play an increasingly important role. REFERENCES
Gary McGraw is vice president of business development at Reliable Software Technologies. He holds a dual PhD in cognitive science and computer science from Indiana University and a BA in philosophy from the University of Virginia. McGraw coauthored both Java Security: Hostile Applets, Holes, and Antidotes (John Wiley & Sons, New York, 1996) and Securing Java: Getting down to Business with Mobile Code (Wiley, 1998) with Ed Felten. He has published over 50 peer-reviewed technical papers and is principal investigator on grants from Air Force Research labs, DARPA, and NIST's Advanced Technology Program. McGraw is a member of the IEEE, AAAI, and Cognitive Science Society. Readers
may contact McGraw and Felten via email. Send general
comments and questions about the IEEE Internet Computing Online website to Copyright (c) 1998 Institute of Electrical and Electronics Engineers, Inc. |