COMP 3000 Essay 2 2010 Question 2

Paper

Trust and Protection in the Illinois Browser Operating System

http://www.usenix.org/events/osdi10/tech/full_papers/Tang.pdf

Shuo Tang, Haohui Mai, Samuel T. King

University of Illinois at Urbana-Champaig

Presentation slides to go along with the paper: Trust and Protection in the Illinois Browser Operating System. http://www.cs.uiuc.edu/homes/stang6/ibos.html#slide1

Background Concepts

In the world we are in, the web is everywhere and runs in different operating systems and browsers. The Illinois Browser Operating System (IBOS) is not just a new browser to improve security, it is also a full operating system. It was developed by three graduate students at the University of Illinois. It’s main goal is to expose browser-level abstractions at the lowest possible software layer, reducing the trusted computing base for web browsers. Many websites and web applications have become major targets for attackers and hackers. These attackers are always finding new ways of exploiting even the most secure systems. Just recently, cross-site scripting (XSS) has become the most common security vulnerability over the age old buffer overflow [1].

Plenty of research has gone in to improving security among the various web browsers on the market today but all browsers still remain susceptible to attacks on the lower layers. Compromised Ethernet drivers can send sensitive HTTP packets to third parties, compromised storage modules can send persistent data to unwanted viewers and compromised window managers can overlay fake interfaces common in phishing attacks [1]. Common web browsers run on top of commodity operating systems with shared system services and user-mode libraries, increasing the trusted computing base(TCB). IBOS looks to solve this issue by exposing browser-level abstractions rather than just general-purpose abstractions. Important concepts such as cookies, HTTP connections and tabs for displaying pages are all brought into the browser abstraction layer. By moving all of these subsystems, the IBOS system ultimately aims to reduce the computer's TCB.

Monolithic vs Modular

The internet today has become an important part of our lives, it is used everywhere and in everyday life. It all started with the user only being allowed to read and browse the content, but today the expansion has led to allow the ability to write our own content and have our own impact on the rest of the world. The introduction of Web 2.0 brought upon an enormous change to the web, as well as introducing the concept of security concerns. Modern web applications are mostly designed to meet a newer modular architecture.

Modularly designed architecture browsers such as Chrome are designed in a way that each browsing instance is assigned to a unique operating system process. It is designed to perform much better in terms of fault-tolerance, accountability, security, memory management and performance. Chrome has the ability to be able to run even when another web program crashes. Memory management in a modular architecture is designed to handle each process at a time and when the program closes the memory space is ready to be used by another program. Scheduling for modular browsers handled at the OS level and web programs are able to run parallel.

Monolithic architectures browser such as Firefox, are monolithic and easy to exploit, since they run in a single address space. It is designed in a way that all the components for the web run in a single process. Disadvantages about monolithic architectures are that if a single web program crashes, then all of the other web browsers also crash. This can cause all of the data to be lost that is currently saved. Memory management is also considered poor in a monolithic architecture because it allocates memory at the beginning of the web program and may contain leaks. This is a major problem, because when the program finishes execution, the memory leak will have grown exponentially.

TCB

The TCB is the hardware and software that is critical to the computer's security. It's a combination of kernel and trusted processes made of hardware, firmware, and software that are critical to a computer's security [2]. In the words of Lampson et al., TCB is defined as:

"a small amount of software and hardware that security depends on and that we distinguish from a much larger amount that can misbehave without affecting security." [3].

Modern operating system-browser combinations have massive TCBs that may have several millions of lines of code. By extracting components such as device drivers from the kernel, one can lower a systems TCB considerably. If a device driver is outside of the TCB and becomes corrupted, the effects would not be too severe, but if the driver is left in the TCB, then the results could be cataclysmic. By removing elements from the TCB, it becomes smaller, thereby reducing the risk of having an attack get inside.

Research Problem

Modern browsers, such as Google Chrome and Mozilla Firefox, are continuously being revised and updated to keep ahead of the latest attacks, but continuously have hundreds of security vulnerabilities. Most of these attacks are simple, mostly harmless assaults on web applications, but many attacks are on the browser or even the operating system and its libraries. Since the browser runs lower on the shared storage stack, a successful attack on a browser can have horrible repercussions because it gives access to all of the browser data for all of the web applications. It also provides the attacker with access to other resources on the system which is being exploited. An attack on the operating system can be disastrous if it is successful and may cause serious damage to the entire system. This is partly because the attackers can access arbitrary states and events, allowing them to have full control over the system. The focus of this research is to prevent and decrease the attacks on the browser, libraries, operating systems and system services.

Contribution

Architecture and Design

The authors have developed IBOS to reduce security risks, without compromising speed and efficiency. One of the ways they have achieved this is through their implementation of process creation. Essentially there are two types of processes. A web page instance and a traditional process. Any time the user opens a new tab, clicks on a link, or enters a web address in the uniform resource locator(URL) bar, the IBOS kernel creates a new process. Upon creating a web page instance process, the kernel labels it with the originating address of the HTTP request. If a web site such as facebook.com decides to host an outside script, also known as an iframe, from another website, the kernel creates a new process for the embedded script and labels it appropriately. Traditional processes are every other process that is created for the local machine. These processes are simply labeled as localhost.

An IBOS label contains a protocol, domain and port. By creating unique labels for each web page instance, the kernel can isolate them from one another. This prevents a compromised component from taking control of other processes. Also by labeling where requests come from, the IBOS kernel can ensure that the data it is receiving is in fact from the expected origin. Each time a process makes a request, the kernel checks to ensure that the process is in fact allowed to access the requested resources.

Each time an HTTP request comes in over the network, the network process renders the HTTP into a TCP stream, which is in turn converted into a series of Ethernet frames that are sent to the network interface controller(NIC). By doing all of this, the process is excluded from accessing any data structure. The process must first pass through the kernel before it receives what it has requested.

Through the use of twelve security invariants, the development team ensures that subsystems behave according to their intended purpose without interfering with other subsystems. The invariants are designed for different components such as driver, storage, network processes, and UI.

For driver invariants, IBOS ensures drivers do not access DMA buffer directly and devices can only access validated DMA buffers. their approach is to separate the the management of device control registers from the use of device buffers. Using this separation, processes can fill device specific buffers for DMA transfers, and the IBOS kernel instructs the driver to enforce the device to use a verified DMA buffer.

In the storage invariant, IBOS encrypts all objects before passing them to the storage subsystem. That way all of the key-value pairs maintain confidentiality and integrity even if the storage stack itself becomes compromised.

The network process invariants are where the security is focused. The first two invariants are: The kernel must route network requests from web page instances to the proper network process, and the kernel must route Ethernet frames from the NIC to the proper network processes. To enforce all of these invariants, IBOS puts all network processes in their own protection domains. By putting network processes in their own protection domains, the kernel naturally ensures that network requests from web page instances and Ethernet frames from the NIC are routed to the correct network process. The third invariant is that the Ethernet frames from network processes to the NIC must have an IP address and TCP port that matches the origin of the network process. IBOS kernel checks all outgoing Ethernet frames before sending them to the NIC to check the IP address and TCP port against the label of the sending network process. The fourth invariant is HTTP data from network processes to web page instances must adhere to the SOP. The IBOS kernel inspects HTTP data before forwarding it to the appropriate web page instance and drops any HTML documents from different origins. The last invariant is that network processes for different web page instances must remain isolated by labelling the origin of the web page instance.

As for the UI subsystem, IBOS kernel enforces 3 invariants. The first is the browser and web page content displays are isolated by using a frame buffer video driver and page protections to isolate portions of the screen. The second invariant is that only the current tab can access the screen, mouse, and keyboard by mapping the frame buffer memory region and routing mouse and keyboard events into the currently active web page instance. the final invariant is the URL of the current tab is displayed to the user by using the kernel display area to display the URL.

The IBOS kernel also offers custom security by allowing web sites to specify a server-side policy file that IBOS retrieves to restrict network accesses for a web page instance.

The security of the window manager in the browser is achieved by dividing the window into three exclusively owned horizontal sections. The top bar of the page can only be accessed by the kernel. This is where the URL, labelled by the kernel is displayed. The second section is controlled by the browser UI, which the developers have called the chrome. This is where the back buttons, URL bar and other objects found in various browsers are located. The rest of the page is reserved for the web page instance. This is where the web page is displayed. Although this division of responsibilities cannot completely eradicate phishing attacks, it does however give the user a better chance to realize that something is wrong. By displaying the URL as defined by the kernel in the uppermost bar, the user can see exactly which website is being displayed.

IBOS has a considerably smaller TCB compared to other modern browsers. Where both Chrome and Firefox come in at over 4 million plus lines of code in their trusted computing base, IBOS has only about 42,000. Since IBOS isolates each process, it was also able to prevent between 75-100% of vulnerabilities from affected components on a machine. Using Chrome, the researchers tested 175 known issues on the IBOS kernel which ranged from memory exploits to interface spoofing. Out of all the known issues, IBOS was able to prevent 135 or 77% of the issues whereas Chrome was only able to contain 83 of them. The issue is that Chrome is able to catch exploits in its rendering engine since it is in a sandbox but any exploits that took advantage of the browser kernel could not be prevented. This is not a problem for IBOS because many of the browser components inside the trusted computing base in Chrome have been brought outside of the IBOS TCB limiting what can be done with exploitation. IBOS also contains tabs abstraction which multiplexes the display between different web pages instances. Input devices are programmed to route to a visible tab, which prevents keylogger from hijacking another instance's session.

Performance

In terms of performance, IBOS is comparable to the two best performing web browsers currently released: Firefox and Chrome. For websites such as Google Maps and Facebook, IBOS actually performs much better than Firefox while loading pages. This may be due partly to the fact that IBOS was developed with the WebKit engine, which has been optimized to run Google Maps. For Facebook and Wikipedia, sites that use many HTTP requests, IBOS performs slightly slower than the other two browsers, but for the others, where there are only a few HTTP requests, IBOS runs just as quickly as the others.

Critique

Structure

This paper was very well organized and well executed. It naturally flows and keeps order in what it is trying to explain without the need to flip back and reference another piece of content in the paper. Starting with the core mechanics of why it is needed to how the kernel is organized and working its way up to many high-level pieces of information it felt like a natural progression of ideas, giving you the information you need to understand upcoming concepts.

Evaluation

The evaluation of the IBOS security has some flaws, it is not very thorough and the data is potentially confounding. When the authors were testing two systems that could not be compared head-to-head, they made many assumptions that could possibly be wrong.

The IBOS has shown through internal testing that it is able to resist 77% of attacks from a set of 175 security bugs whereas Chrome is only able prevent 46%. The improvement sounds impressive however, the set of security bugs they tested against was obtained from Google “Chrome’s bug tracker”. The fact they are comparing known security flaws in Chrome against the new IBOS makes their improvement of 31% far less impressive.

In addition, Their initial test set contained 217 bugs with duplicates removed, and 42 bugs were omitted because they were denial of service attacks and the IBOS does not protect against that form of attack. It is understandable this is out of the scope of this research. However, that is a big set of flaws which are not addressed.

Furthermore, the researchers only compared their results against the Chrome web browser. A comparison which also includes other browsers such as Mozilla Firefox, Internet Explorer and Safari would be much more compelling.

References

[1] CVE - Common Vulnerabilities and Exposures (CVE). http://cve.mitre.org.

[2] Rushby, John (1981). "Design and Verification of Secure Systems". 8th ACM Symposium on Operating System Principles. Pacific Grove, California, US. pp. 12–21.

[3] B. Lampson, M. Abadi, M. Burrows and E. Wobber, Authentication in Distributed Systems: Theory and Practice, ACM Transactions on Computer Systems 1992, on page 6.