Meeting Minutes
Meeting Date: 15 October 1999
Attendees:
Brad Arkin, RST, Inc.
Lee Badger, NAI Labs
Bob Balzer, USC-ISI
Penny Chase, MITRE
Bob Clemons, NSA
Ed Felten, Princeton
Virgil Gligor, U. Maryland
Joshua Haines, MIT - Lincoln Labs
Carl Landwehr, Mitretek
Jay Lepreau, U. Utah
Tom Markham, Secure Computing Corp.
Gary McGraw, RST, Inc., Chair
Greg Morrisett, Cornell
Peter Neumann, SRI
Carl Piechowski, DoE
Avi Rubin, AT&T Labs
Sami Saydjari, DARPA
Mike Skroch, DARPA
Tim Teitelbaum, Cornell/Grammatech
David Thompson, Mitretek
Roger Thompson, ICSA
Paul Walczak, Army Research Lab
Brian Witten, DARPA
Agenda
This initial meeting of the InfoSec Research Council's (IRC's) InfoSec Science and Technology Study Group (ISTSG) on Malicious Code met at the Westfields Marriott in Chantilly, Virginia October 15, 1999.
I. Charge to the group
Sami Saydjari, representing the IRC, charged the group to find ways to counter the threat from Trojan horse and mobile code, which the IRC has found to be an increasingly difficult problem. One approach to attacking the problem is to break it up into smaller chunks. He made a specific point that sandboxing is outside of the group's scope, as is intrusion detection. A primary focus is to determine ways to detect sleeper code before it does its damage.
Virgil provided some historical perspective. Ancient history in this field is 1969-1989. His focus is on malicious software, although malicious hardware was a significant threat during this time. The environment in which malicious code thrives is one that is very common today: that code is explicitly or implicitly shared between malicious author or code-flaw discoverer and unsuspecting users and that the execution environment is poorly confined.
Categories of malicious code are those with memory, those that contain logic or time bombs, viruses which replicate themselves, trap doors with secret entry codes, covert channels that violate data flow policies, and deliberately inserted flaws for future exploitation. Virgil cited first instances of each of these types of malicious code and the early countermeasures and why most failed. He explored in more detail one specific countermeasure, the in-house development of all applications to eliminate outside malicious agents.
The organization of software is changing. Instead of writing applications, programmers write frameworks into which generic modules can be placed, often dynamically. The modules are developed all over the world and each can implement its own interface protocols. Some modules ship with the product, providing the standard features. Others are installed later by the user or dynamically installed when needed. And these modules can provide frameworks for still other sets of modules that define other interface protocols.
Current methods of protecting users from malicious mobile code are code signing, isolation and memory safety, and access control at the interfaces. Users think signed code is safe and not malicious, however, the signer is usually not vouching for the code but merely endorsing a long statement in legalese. Common misconceptions are that the non-malicious code is safe code, that the only relevant security property is goodness, that goodness is compositional, and that good code is good in all environments (the root of the problem with Netscape's code signing mechanism). Code signatures could be improved by having a signature assert a security property. Isolation and memory safety will be more fully explored in Greg Morrisett's talk, but, in short, it cannot cover all the properties we care about. Access control at the interfaces is usually an all-or-nothing policy, lacking flexibility and leading to overly permissive policies. The Java approach is an all-or-almost-nothing policy that allows access to only unconditionally safe interfaces.
Ideally, we want flexible control over policy at the interfaces, including both kernel and application framework interfaces. The current implementations are much too cumbersome for wide deployment. Can we make APIs safer so that policy decisions can be made easier? Static code scanning is a tempting solution, but is limited to finding known viruses and hostile programs and only the simplest new attacks. It is hopeless against unknown sophisticated attacks.
Roger Thompson noted that the Immune system produced by IBM and Symantec is able to auto-detect new viruses.
Greg described the current practice of mobile code protection as implemented in the Java Virtual Machine (JVM), identifying the vulnerabilities and impracticalities inherent in making them safe. The security model is simple and supports only simple policies, policies cannot be set by users, performance is poor, it is only practical for supporting Java, and the trusted computing base is too large. A better alternative is to have code proven to be safe in the client before execution, but theorem provers are very slow. However, whereas proving a theorem is hard, verifying a proof can be much easier, so one approach is to have programmers add proofs to their code, which the client can verify before execution. This supports more flexible policies while requiring proof generation only once for each code.
Greg's Real World Problem #1 is how to generate proofs. Manual generation is too painful and interactive provers are only practical for small number of programs. We need fully automatic provers.
Real World Problem #2 is the size of the proofs. They generally dwarf the code they prove.
One approach to solving both problems is to restrict the policy only to type safety. Type safety is necessary for most policies anyway. Performance advantages can be obtained by integrating the compiler and the prover. Touchstone, an example of such an integrated prover developed by Necula, compares very favorably with the JVM in performance. However, limitations in language complexity and proof size are still issues.
Greg then presented Typed Assembly Language (TAL) as a way to support many high-level languages and to keep the proof size small and linearly scalable. An implementation at Cornell demonstrates that TAL is a step in the right direction. Type safety as a security policy gives the proof for free, it supports general-purpose high-level languages with many (but not all) optimizations and higher-order type constructors.
So, what's next? Type safety is just the beginning. It proves only static capabilities and does not address resource bounds or other liveness properties, and there are still the other hard issues: trust management, information flow, authenticity, etc. Promising work is being done with Security Automata by Schneider and with Software Fault Isolation.
In summary, there have been big changes since the '70s. Formal memory safety has been mastered, software-based enforcement is good, and the trusted computing base has become much smaller. But there is still a lot to do, particularly regarding liveness and global properties. And, "Would any of this stopped Melissa?" No. Security is hard. Major advances in type and proof systems are having an impact. The Java hype has focused type and proof systems on important but tractable problems instead of full program verification.
Neumann: The TCB gets too big when absolute type safety is implemented.
Felten: Type safety is not security. Security relies on the semantics of a program, not on typing data correctly.
Morrisett: A significant failing of formal methods is that no one ever writes formal specifications. Hardware engineers used to write formal specifications before they built components, but now they do just the opposite. Will software development go the same route?
Discussion that dynamic type-checking is required for efficient implementation. Noted that dynamic checks can be proven statically with proper insight into the compiler, or with hints supplied by the compiler.
It is a challenge to define a language for the formal specification of a security policy.
Morrisett: One solution is to require programmers to provide more evidence of quality and security, in the form of a proof, which can be statically verified fairly efficiently prior to execution.
Neumann noted that reasoning about composition is important and has practical applications.
The group was asked to characterize the worst example of a virus. Roger Thompson proposed the Chernobyl virus, because its payload wrote the BIOS Flash ROM, requiring a considerable effort to restore the computer to a bootable condition. A list of the worst viruses was made, in no particular order: Melissa, Explore.zip, Russian New Year, FreeLinks, Thompson compiler Trojan horse, e-mail worms, Easter eggs, Worm, ActiveX, Back Orifice, NT problem, Applet compositions, Happy 99, CRH, and domain specific attacks.
Sami pointed out that from our perspective, stealth criteria are more important than the payload. For example, we're more concerned that the code being rewritten for Y2K is vulnerable to the insertion of malicious code than what it is that code might do. We assume the worst payload. Major concerns are denial of service, integrity compromise, and information leaking, in that order. It was suggested that denial of service was less important than integrity. Sami defended his ordering by noting that denial of service can often be accomplished without penetration.
Skroch: Firmware should be considered as code, too. He also described Microsoft's problems with Easter eggs. Much of their software development is farmed out overseas and it is too large to be inspected effectively. If they can't control Easter eggs, a form of trap door, they cannot control malicious code. Sami noted that code that is designed to be hidden is much harder to detect than error code.
Carl Landwehr asked how the Thompson compiler recognized when it was compiling the compiler or a login module. Greg noted that the Thompson Trojan horse can be defeated by repeated compilation of the compiler with various compilers, and that Reliable Open Source (ROS) is an effective countermeasure, in spite of threats posed by the Thompson compiler type mechanisms.
Gary asked what general solutions are available to defeat viruses. The group listed: code signing, automatic Petri dish (a heuristic analysis step sends suspected viruses off to a lab for further analysis), and wrappers that implement a security policy (through static analysis). Defenses must be fault tolerant like the Human immune system, and they must be application-aware. The latter puts an extra burden on programmers and on users.
Lee thought that modest goals are achievable, but realistic ones are very hard to implement. The reason is historical in that systems have grown to share resources. Reality is changing. The increasing use of Java instead of C is eliminating some common vulnerabilities, such as buffer overflows and pointer errors. And disk drives are getting large enough that we may never delete files in the future, reducing the damage capable of being inflicted by malicious code. On the other hand, smaller implementations, such as PCs in cellular phones, may create a new venue where limited storage capacities will continue to require storage reuse.
Another suggestion was made to dedicate computers to applications and connect them with narrow channels, which are easier to defend. Compare the rather narrow semantics of SMTP, for example, with the semantic breadth of the X86 instruction set. Firewalls only work because of the narrowness of the network protocols.
Sami suggested that the group look to the future and see what's left that needs to be done.
Tom proposed providing more than two levels of trust (a la Multics). However, one problem is that the operating system is not always aware of, for example, Java applets and the environment which application programs provide for them, as he noted in his presentation.
After lunch, Sami presented his taxonomy of the solution set.
Gary presented his Scenario 1, for the near future (tomorrow). His bullets were: Infrastructure, No control over design, Some ability to inject stuff, and the question, "What do we do?" He elaborated that the DoD infrastructure is one of many infrastructures critical to the country, and that we can either keep people away from broken systems (through complete isolation or via firewalls) or fix the broken systems. He then asked the group to consider the best way to apply $1B to the solution of the malicious code problem.
Greg proposed fault tolerance has promise, though for the longer term.
Bob Balzer suggested that wrappers might be a significant part of the solution. They primarily provide protection and secondarily find new attacks. Greg noted that there is no existing language in which to express any but the simplest security policies and that creating one is hard. Carl proposed three areas of research: How to specify the general area of security to enforce, how to state the specific security policies, and how should they be composed.
Virgil suggested doing less theoretical stuff and more practical stuff, although the practical stuff is often harder to predict. For example, firewalls and virus detectors ended up being effective while Multi Level Systems (MLS) did not. We should look at the prospective uses of systems and try to figure out what and where the most likely solutions can be implemented.
Gary thought customers are worried about how to make programmers put more useful characterizations of required security policy in the code or generate code more conformant to specific policies and in constraining the execution of these programs accordingly. He noted that DOS is considering eliminating the use of all mobile code.
Avi offered software distribution as a significant problem.
All agreed that there would be no single solution.
Gary then presented his Scenario 2, for the long term. Your toaster is on the net, there is no such thing as "program," the infrastructure is being rebuilt, and mobile code is the norm. How do we cope with software behavior?
Peter suggested that open source has promise. DARPA and the DOD are interested. Even if open source does nothing but goad Microsoft into building a good OS, that is a desirable result. (Humorous comment about Steve Lipner now being Microsoft's pretend security guy.) It was pointed out that malicious code is more likely found in applications than in the OS. Applications can be open source, as well.
Peter then outlined his vision of a trustworthy architecture for the future. There are thin clients on the desktop, programs execute on trustworthy sites connected by bi-level trusted paths, and all server software is open source.
The following issues were raised regarding Scenario 2. There are different levels of trust and different trust mechanisms for the OS and applications. The major difference between the scenarios is that we have more time to prepare for Scenario 2. A major issue will be code mangling and other obfuscation techniques that malicious mobile code servers will use to circumvent protection mechanisms. There will also be a shift in the code installation time scale, as it is more likely that components will be updated dynamically over the net in a just-in-time fashion rather than having humans purchase or download and install software.
Gary envisions distributed program with millions of parts, some of which will likely be sold per-use. Peter noted even a mature system like the phone system, which has been hacked for a long time, can still be dialed into and controlled with the knowledge of a single password. It will be hard to secure the kind of environments that Gary posits. Virgil thought that companies might withdraw from the Internet and isolate their networks. Avi pointed out that the opposite trend is in effect and that, continuing with the phone company example, they plan to abandon their private networks and put everything on the Internet.
Gary stated that Proof-Carrying Code depends upon the availability of proper security policies, which are in short supply. Tom proposed diversity of application as a fault tolerance mechanism, since a bug or vulnerability would not effect all the word processing programs, for example, at the same time.
Gary led the group in identifying the technologies that are available now that would be able to help in the short term-the next six to 24 months. We came up with:
Proposed locations are University of Utah, AT&T in New Jersey, or Menlo Park.
Suggestions for additional invitees are:
This site hosted and maintained by Reliable Software Technologies
II. Ancient History: Why Malicious Code is not a Brand New Problem (Virgil Gligor)
III. The State of the Art: Why Sandboxing and Code Signing are no Panacea (Ed Felton)
IV. Why Languages and Compilers Matter (Greg Morrisett)
V. Discussion
We then made a similar list of technologies that might help in the long term, as follows:
The difficult problems we have not addressed, the leftover holes, are:
More information can be found about insider attacks at www2.csl.sri.com/insider-misuse.
VI. Plan January workshop
Proposed dates for a follow-on workshop in January are 13-14 and 20-21.
Suggested topics for the January meeting are:
Comments, etc. to webmaster@rstcorp.com
Copyright ©1999-2000