Overview

The computing industry has been rapidly transitioning to a software-as-a-service paradigm, embracing service portability across devices, enabling rapid cycles of innovations from software vendors, and incurring minimal software management from users. Services differ from traditional applications in three fundamental ways: 1) a service's master copy is remote (in the cloud); 2) services are untrusted to access one another or user-private resources (like sensors or data); 3) services often embed other services to enable rich service compositions. These differences have significant implications on the design of client operating systems in terms of protection, resource sharing, and access control. In the ServiceOS project, we rethink the client platform design in these dimensions. Our ServiceOS vision is detailed in this HotSec position paper.

MashupOS

Our first subproject is MashupOS, where we observed that web sites are OS principals on web browsers and web applications demand browsers to offer OS abstractions for protection and cross-principal communication. The full paper on MashupOS was published at SOSP 2007 and a position paper was published at HotSec 2007.

Gazelle

Although web browsers function as operating systems, they have never been designed and implemented as an OS. We then built the Gazelle web browser, which is the first browser that uses a multi-principal OS-based design and construction, where web sites are OS principals and unit of protection, and where all OS logic (such as the same-origin policy and resource access) is located exclusively in a browser kernel in a separate protection domain from that of browser renderers. We detailed this work in a paper published at Usenix Security 2009. The special characteristics of services also required rethinking resource scheduling, which is detailed in this technical report.

WebAnalyzer

With any new browser design, one often worries about its compatibility cost. Gazelle enforces a unified same-origin policy (SOP), applying SOP to all resources (DOM or cookie or remote access) and to all content types (HTML, Flash, Java programs or images). In contrast, existing web browsers' access control policies have evolved piecemeal in an ad-hoc fashion with the introduction of new browser features, resulting in numerous incoherencies. Although we can make Gazelle compatible with existing browsers through the use of cross-principal communication, we want to enable browser vendors to make informed tradeoffs between security and compatibility and have a data-driven browser design. To this end, we built a WebAnalyzer tool to crawl the web, emulate page browsing, and measure the compatibility cost of ridding unsafe browser features. We detailed this work in a paper published at Oakland 2010.

HTTPi for practical end-to-end web integrity

Widespread growth of open wireless hotspots has made it easy to carry out man-in-the-middle attacks and impersonate web sites. End-to-end security between a user’s web browser and web sites is ever more needed to allow meaningful enforcement of the same-origin policy on the web browser platform. Although HTTPS can be used to prevent such attacks, its universal adoption is hindered by its performance cost and its inability to leverage caching at intermediate servers (such as CDN servers and caching proxies) while maintaining end-to-end security.

To complement HTTPS, we revive an old idea from SHTTP, a protocol that offers end-to-end web integrity without confidentiality. We name the protocol HTTPi and give it an efficient design that is practical to deploy for today's web. In particular, we tackle several previously-unidentified challenges, such as supporting progressive page loading on the client's browser, handling mixed content, and defining access control policies among HTTP, HTTPi, and HTTPS content from the same domain. Our prototyping and evaluation experience show that HTTPi incurs negligible performance overhead over HTTP, can leverage existing web infrastructure such as CDNs or caching proxies without any modifications to them, and can make many of the mixed-content problems in existing HTTPS web sites easily go away. Based on this experience, we advocate browser and web server vendors to adopt HTTPi.

ServiceOS generalization

We further generalize Gazelle's design to that of a client OS. With cloud-centric computing, remote content has become the first-class citizen for all applications including not only web browsers, but also document-processing applications, such as word processors, photo viewers, and media players. The implication here is that the client OS needs to adopt the same-origin policy kind of mentality from browsers and offer protection for remote content of different owners to all applications. We are pursuing an OS design that offers this protection while being compatible with existing web security policies and at the same time allowing easy adaptation of existing native applications. Our paper on this topic is under submission.

User-Driven Access Control with Access Control Gadgets

Modern client platforms, such as iOS, Android, web browsers, and ServiceOS, run each application in an isolated environment with limited privileges. A pressing open problem in such systems is how to allow users to grant applications access to user-owned resources, e.g., to privacy- and cost-sensitive devices like the camera or to the user's data that resides with various applications. A key challenge is to enable such access in a way that is non-disruptive to users while still maintaining least-privilege restrictions on applications. We propose user-driven access control, whereby permission-granting is built into existing user actions, rather than added as an afterthought via manifests or prompts. To this end, we introduce two OS-level techniques, access control gadgets and kernel-recognized gestures, for controlling access to user-owned resources. This work is published at Oakland 2012 and received the best practical paper award.

Permission Re-Delegation: Attacks and Defenses

Permission re-delegation occurs when an application with permissions performs a privileged task for an application without permissions. This undermines the requirement that the user approve each application's access to privileged devices and data. We demonstrate this risk by launching real-world attacks on Android system applications; several of the vulnerabilities have been confirmed as bugs. We have devised a new OS mechanism, called "IPC Inspection" for defending against permission re-delegation. IPC Inspection prevents opportunities for permission redelegation by reducing an application's permissions after it receives communication from a less privileged application. We have published a paper on this at Usenix Security 2011.

Clickjacking: Attacks and Defenses

Clickjacking attacks are an emerging threat on the web. In this paper, we design new clickjacking attack variants using existing techniques and demonstrate that existing clickjacking defenses are insufficient. Our attacks show that clickjacking can cause severe damages, includingcompromising a user’s private webcam, email or other private data, and web surfing anonymity.

We observe the root cause of clickjacking is that an attacker application presents a sensitive UI element of a target application out of context to a user (such as hiding the sensitive UI by making it transparent), and hence the user is tricked to act out of context. To address this root cause, we propose a new defense, InContext, in which websites (or applications) mark UI elements that are sensitive, and browsers (or OSes) enforce context integrity of user actions on these sensitive UI elements, ensuring that a user sees everything she should see before her action and that the timing of the action corresponds to her intent.

We have conducted user studies on Amazon Mechanical Turk with 2064 participants to evaluate the effectiveness of our attacks and our defense. We show that our attacks have success rates ranging from 43% to 98%, and our InContext defense can be very effective against the clickjacking attacks in which the use of clickjacking is more effective than social engineering.

ServiceOS Demo

Technology transfer

The communication abstraction proposed in MashupOS influenced the design of the "postMessage" cross-domain communication API in HTML5, which is now implemented in all major browsers.

The sandbox abstraction proposed in MashupOS resulted in "iframe sandbox" specification in HTML5, which starts to see browser adoption.

Learning from the MashupOS experience, we developed an Ad isolation system using cross-domain iframes for Microsoft Ad Center. Our system is now adopted. Microsoft has also proposed the corresponding API, called Microsoft Display Ad SmartServe API, for standardization in the Ad industry.