COMP 3000 Essay 2 2010 Question 2

From Soma-notes
Revision as of 04:01, 3 December 2010 by Gsmith6 (talk | contribs)

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, you make it 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, slightly harmful 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 application. 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 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 which leads to reduced TCB. One of the ways they have achieved this is through the use 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.

IBOS has 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.

IBOS have the same functionality as Firefox and Chrome which uses the standard Web kit but it gives better performance.

Security

In addition to labels, IBOS has other approaches at reaching their goals in security. Security variants are a way for IBOS to enforce their subsystems to perform their designated functions without interfering with other subsystems. To reach this goal, they designed invariants for different components such as driver, storage, network processes, and UI invariants.

For driver invariants, IBOS insures 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 storage invariant IBOS encrypts all objects before passing them to the storage subsystem. That way All of our key-value pairs maintain confidentiality and integrity even if the storage stack itself becomes compromised.

Critique

Structure

This paper was very well organized and 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 set the testing against is potentially confounding.

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 researches 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.