The Darpa Browser

This is the document accepted by Darpa, and is presented as is for historical interest.
Current terminology and screen shots have changed since then.

Executive Summary

Using the capability-secure open-source E programming language, and the Combex-proprietary Capability Windowing Toolkit (capWT), Combex will develop a capability secure Web browser: the HTML rendering engine for the browser will be capability confined [Lampson1973, Shap2000] so that it may not compromise any part of the system, not even the field in the browser which displays the URL.

The browser will be run on an "E Language Machine". The E Language Machine is a capability secure, trustworthy platform, built on a Sanitized Linux: a Linux from which everything has been stripped that is not needed to support the E Language Machine. In particular, all the services normally associated with Linux (terminal services, network services above the TCP/IP stack, etc.) will be removed, eliminating risk of compromise. The E Language Machine will be a fully functional computing system, but, besides the TCB, only programs written in E and confined as caplets (capability-secured applications) will be permitted to execute.

Combex will supply 2 rendering engines. A Benign Renderer will underpin the web browser for traditional browsing purposes. A Malicious Renderer will, when loaded, relentlessly attempt to escape from its capability confinement, reporting on its results as it makes attacks.

Combex was founded by, and is led by, the core developers of the E language system and the publicly available applications written in that language. Bringing the powers of E, E's developers, and the Capability Windowing Toolkit together in a single focused effort on this contract allows Combex to deliver a reliable, robust capability secure system at high speed and with essentially no risk.

Statement of Work

Objective: Provide a brief overview of the specialty area and what is to be accomplished

Capability security embodies a paradigm for secure computational systems that stands in stark contrast to conventional security systems based on Access Control Lists. Capability security is designed to provide extremely fine-grain control of resources, making the allocation of each specific resource a separate granting of authority. Access Control Lists may be thought of as systems of ID badges, with each badge granted a span of powers, with the list of powers for the ID relatively fixed; capabilities may be thought of as keys, one for each resource, which may be granted and reclaimed during processing, so that a program might, over the course of a computation, hold dozens of keys, but never actually hold more than a few at a time.

Combex will develop a capability secure Web browser in which an incorrect page rendering module (made incorrect either by the presence of bugs or by malicious code) cannot compromise any other aspect of the computer or the display, up to and including the presentation of the URL from which the page was fetched.

Scope: Provide a statement of what the SOW covers including the area to be investigated, objectives/goals, and major milestones.

This project will investigate the application of capability security to a client application problem of moderate complexity, namely, the confinement of an HTML rendering engine in such a fashion that it cannot compromise other parts of the system. It will demonstrate the flexible power of capability security to enable a broad spectrum of safe, reliable computing without locking the user or the system into a structure that does not allow meeting diverse computing requirements. The major milestones include:

Task/Technical Requirements: Provide a description of tasks, which represent the work to be performed, developed in an orderly progression and in enough detail to establish the feasibility of accomplishing the overall program goals.

Technical Approach and Relevant Capabilities

Combex and its Relevant Technologies

Combex was founded in 1999,to pursue opportunities for capability security in the financial and software development sectors. Combex is the home of the world's greatest repository of expertise on the capability-secure, open-source E Programming Language. The Chief Technology Officer (CTO) of Combex is Mark Miller, the chief architect and implementor of E, and the central coordinator of open source E project. The Chief Operating Officer (COO) of Combex is Marc Stiegler, the developer of over half of all publicly available E applications deployed in the world today, and author of the book (currently in draft form) E in a Walnut [Stiegler2001]. In addition, Mr. Stiegler is the chief architect for the Capability Windowing Toolkit (capWT), a proprietary Combex technology for imposing capability discipline on mutually suspicious application subsystems that must share screen and keyboard/mouse resources in a graphical user interface (gui) environment.

E itself is the result of over $10M of research and development over a seven year period; its development was first initiated by the company Communities.com for the implementation of a capability secure decentralized social virtual reality. When Communities.com abandoned development of its own virtual reality for marketing reasons, Communities.com allowed Mr. Miller to open source the language and take control of the central repository.

The most mature version of E, version 0.8.9, runs on top of the Java Virtual Machine (jvm), versions 1.3 and above. The language not only implements capability security within single-computer applications, it applies capability security to distributed systems with strong encryption that is built into the infrastructure: E programmers are not burdened with security considerations for their distributed systems, all communication is automatically encrypted, and remote computation objects are automatically authenticated. In addition, E uses a promise-based architecture for distributed computation, eschewing threads for concurrency control. This eliminates the traditional Sword of Damocles that hangs over all thread-based programming, the threat of deadlock. A particular feature of E critical to the success of this project is the power to implement caplets, software applications that are confined by capability discipline even if they share cpu, disk, and memory resources.

A more complete description of the specific characteristics of E that make it a "capability secure language" can be found in the References. Further reading on E's other special and powerful characteristics can also be found in the References at the end of this proposal.

Though E is missing several features needed for a version 1.0 release, all implemented features have been proven robust through a series of actual application development efforts including:

Figure 1: Securit-Edesk with windows on Windows, Sun, and Linux file systems

The capWT windowing toolkit is an abstraction layer built on top of the Java AWT/SWING foundation classes for capability secure gui support. Since AWT/SWING is unaware of capability security, it embodies a complex stew of undisciplined powers. capWT, by using a sophisticated array of capability security patterns including revocable forwarders, facets, sealer/unsealer pairs, and pet name systems, turns this froth into a coherent framework for securable gui development: caplets presenting user interfaces through capWT cannot convincingly forge a fake user interface, cannot intercept unintended screen or keyboard/mouse events, cannot generate unauthorized screen or keyboard/mouse events, cannot communicate with or subvert other application systems even when they are sharing the same window, and cannot achieve unauthorized access to files for either reading or writing.

Technical Approach

The basic strategy of development will be to build up an "E Language Machine" from a "sanitized" Linux OS. This machine will be able to run E programs and caplets. It will be a general-purpose computer in the normal sense of the word, having the full Turing-machine power enabled by the E language. But it will be safe from the inadvertent launch of other Linux applications and services that could compromise the system by striking from "below" the E level.

This technical approach is depicted in Figure 1. Starting at the bottom and working to the top, the components of the system are:

We believe that the Sanitized Linux, operating within the constraints outlined above, achieves the goal of creating a trustworthy boot process that cannot be compromised without physical access to the hardware. However, for extra assurance, we have included the Enhanced Secure Boot process as depicted in the diagram as an added-cost option for the contract. This Enhanced Secure Boot process would be implemented using the AEGIS secure bootstrap system currently being integrated with LinuxBIOS [AEGIS].

Renderer Capabilities

What capabilities will be granted to the plug-in renderer? The list of capabilities described here are the only powers the renderer will have; any attempts at malicious behavior will require the use of these capabilities alone.

Implicit authority conveyed to the renderer are the authority to allocate RAM (create objects), consume CPU time (do computations), and deallocate RAM eventually (by removing all references to an object, the object will eventually be scavenged by the garbage collector; since access to the garbage collector is not an authorized capability, the renderer cannot initiate such scavenging itself).

Example Sophisticated Candidate Exploits and their outcomes

We have already described how the renderer is constrained by capability discipline from engaging in simple exploits such as reading confidential data, modifying critical system files, and drawing at will across the user's entire screen. We believe these properties cover all the security requirements stipulated in the FRT. Nonetheless; here is a sample of more complex attacks and their consequences.

Exploit	Outcome
Attempt to use data from one html page to corrupt the data on the next one	The renderer is not allowed state that persists from page to page; each time a new page is loaded, a clean instance of the renderer begins anew.
Transmission of a user's html page to a conspiring web site: It might be useful to the developer of the malicious renderer to have the data from a page the user has accessed. A malicious renderer might try sending the data from the current URL to the conspiring web site by encoding the data in a query string for a page at the conspiring web site, and then requesting that page.	The renderer cannot reach the conspiring web site because only sites specified in the links of the current page can be specified by the renderer (though the users can specify any page they desire, by typing the URL into the URL-designating field controlled by capBrowseFrame). Even if the user loads a page of malicious data, explicitly designed to conspire with the renderer, the renderer cannot transmit any information from any page except the malicious page itself, because of its memoryless condition
Transmission of user's page through a covert channel: By using its ability to allocate RAM and consume CPU resources, the renderer could engage in "wall banging": forcing system performance to rise and fall in a pattern that can be analyzed, from which data can be extracted. A conspiring caplet, loaded and running at the same time as the renderer, could extract this data by “wall listening” and use its own capabilities to further transmit the information.	All known practical security systems are subject to such covert channel “wall banging” attacks, and the best limitation normally attempted is to limit its bandwidth. E addresses instead the other half of the problem, where a true solution is indeed possible. For the conspiring caplet to read bits from a covert channel (to “wall listen”), it must have access to a clock or some source of non-determinism. The web browsing caplet described here cannot wall-listen because it does not have such access.

Security Testing

In addition to performing an in-house audit of the code for capBrowseFrame to ensure no improper capabilities are being conveyed to the renderer, Combex will hire on a consulting basis two well known members of the Cypherpunk/hacker community to review the system and attempt system breaches. The Combex Lead Investigators will assist these "friendly assassins" in every possible way, helping them understand the machinery of confinement, giving them full access to our sources, teaching them how to write their own malicious renderers, and creating new malicious renderers on their behalf as requested.

Furthermore, with the approval of the Contracting Officer, Combex proposes to post the full source for capWT, capBrowseFrame, and both renderers, on the Web and offer $10,000 in prizes for finding a breach. Combex believes that prizes such as this will play a valuable role in accelerating acceptance, and hence adoption, of capability secure tenets throughout the security community.

Coordination

Combex has excellent working relations with the EROS Group in charge of the Extremely Reliable Operating System open-source initiative, and with Agorics, owners of the original KeyKos capability operating system. Combex will work with these teams to ensure maximum interoperability of the results of this contract with their development efforts.

Limitations of the Approach

The greatest limitation of this approach is its dependence on the Java Runtime Environment (JRE). The JRE is an extremely large body of code that has not been reviewed with an eye to its internal vulnerabilities when used in a capability environment. As such, it is not entirely desirable as a part of the Trusted Computing Base (TCB), i.e., the core components of the system that have full authority. Though practical experience to date makes us confident the JRE is up to the current task, a better approach in the long-term would be to use the ENative runtime environment, currently in a nascent stage of development, designed to be deployed with capability operating systems such as EROS.

Key personnel

Mark Miller, the CTO of Combex, will be one of the two Lead Investigators on this effort. Before E, Mr. Miller co-authored the first paper explaining the criteria to be used in designing secure distributed programming languages [Kahn1988]. The languages he’s helped design according to these criteria include Vulcan for Xerox PARC, Trusty Scheme for AutoDesk, Joule for Agorics, Tclio/WebMart for Sun Labs. As noted earlier, Mr. Miller is now the chief architect of E and the central coordinator of the open source E project. In this role he not only manages source code, and design and implementation of future versions of E, he also works to prepare the world for capability security in general. Mr. Miller instigated the E Language Discussion group (e-lang-at-eros-os.org). This email list supports some of the most invigorating discussions of security taking place today, with regular participation by people such as Hal Finney, Jonathan Shapiro, Ben Laurie, and David Wagner. Recently Mr. Miller created CapIDL, an interface definition language for integrating capability secure languages with capability secure operating systems, another milestone on the path to a unified, secure future. Mr. Miller is the inventor on six patents in the areas of cryptographic protocols, automated combination auctions, and distributed secure object systems. He has three more patents pending.

Prior to taking on the central role for E, Mr. Miller was a lead architect for the EC-Habitats capability-secure decentralized social virtual reality under development at Communities.com Communities.com. During the Beta testing for EC-Habitats, no security bugs were ever identified.

Prior to these initiatives, Mr. Miller had over 24 years of experience in software architecture, design and development at companies including DataPoint, Xerox PARC, and Autodesk. At Datapoint, he created the first commercial distributed windows system, VistaView.

Mr. Miller is also the author of "Capability Based Financial Instruments", presented and published at Financial Cryptography 2000. This work unifies the heretofore disjoint research tracks of object-oriented programming, capability security, and public key cryptography into a coherent whole.

Marc Stiegler, the COO of Combex, will be the other Lead Investigator on the contract. As noted earlier, Mr. Stiegler is the author of E in a Walnut, and chief architect and developer of capWT. Prior to joining Combex, Mr. Stiegler was VP of Engineering for Communities.com, where he took on the task of transforming a software development organization that had spent 3 years and $10M without developing either a product or even a justifiable schedule for creating a product. 8 months after Mr. Stiegler took charge, the EC-Habitats capability-secure virtual reality entered into Beta testing.

Prior to joining Communities.com, Mr. Stiegler was the chief architect, designer, and implementer for DecideRight, a decision analysis tool that won the Software Publisher's Association CODIE Award for Best New Business Software of the Year in 1996. Prior to that he was VP of Software Engineering for Autodesk, which was at the time the 4th largest software company in the world. Mr. Stiegler drove Autodesk to be the first professional CAD vendor to ship a product on the Microsoft Windows platform, reinforcing Autodesk's position as the premier developer of CAD on the desktop.

Last but not least, Mr. Stiegler spent 9 years with the BDM Corporation in defense contracting (BDM is now a part of TRW). Mr. Stiegler's career was focused on C3I systems; the systems that today most need capability security to survive the threats of the 21st Century. Mr. Stiegler was one of the few individuals who worked on all 5 of the U.S. Army command and control "stovepipes": maneuver, artillery, logistics, air defense, and intel. Mr. Stiegler's work on the Target Acquisition and Planning System (TAP), which used Apple II computers for tactical nuclear targeting, was in the forefront of the Army's drive to use NonDevelopmental Items (NDI) and Commercial, Off the Shelf (COTS) equipment. Mr. Stiegler was also the Director of Software Development for the battalion-level part of the Distributed Command and Control System (DCCS), which introduced the Army to the GRiD highly rugged yet commercial laptop computer. DCCS was not only used by the High Technology Light Division, it also found application in the White House for communication, and in the Bureau of Land Management for fighting forest fires. A descendant of the DCCS system was used with great success in Desert Storm.

In addition to E in a Walnut, Mr. Stiegler was also the lead author of Programming Languages: Featuring the IBM PC and Compatibles, which was chosen by Byte Magazine in 1986 as one of 20 key books on the PC.

References

[Kahn1988] Kenneth Kahn, and Mark S. Miller, "Language Design and Open Systems," in Bernardo Huberman (ed.), Ecology of Computation (Elsevier Science Publishers/North-Holland, 1988).

[Miller2000] Mark Miller, Chip Morningstar, Bill Frantz, “Capability-based Financial Instruments,” Proceedings of Financial Cryptography 2000, Springer-Verlag, http://www.erights.org/elib/capability/ode/index.html

[Rees1996] Jonathan Rees, "A Security Kernel Based on the Lambda-Calculus", (MIT, Cambridge, MA, 1996) MIT AI Memo No. 1564. http://mumble.net/jar/pubs/secureos/.

[Shap2000] J. S. Shapiro, S. Weber; “Verifying the EROS Confinement Mechanism,” Proceedings of the 2000 IEEE Symposium on Security and Privacy. http://www.eros-os.org/papers/oakland2000.ps