Site Isolation: Process Separation for Web Sites within the Browser Charles Reis, Alexander Moshchuk, and Nasko Oskov, Google https://www.usenix.org/conference/usenixsecurity19/presentation/reis
This paper is included in the Proceedings of the 28th USENIX Security Symposium. August 14–16, 2019 • Santa Clara, CA, USA 978-1-939133-06-9
Open access to the Proceedings of the 28th USENIX Security Symposium is sponsored by USENIX. Site Isolation: Process Separation for Web Sites within the Browser
Charles Reis Alexander Moshchuk Nasko Oskov Google Google Google [email protected] [email protected] [email protected]
Abstract ploitable targets of older browsers are disappearing from the web (e.g., Java Applets [64], Flash [1], NPAPI plugins [55]). Current production web browsers are multi-process but place As others have argued, it is clear that we need stronger iso- different web sites in the same renderer process, which is lation between security principals in the browser [23, 33, 53, not sufficient to mitigate threats present on the web today. 62, 63, 68], just as operating systems offer stronger isolation With the prevalence of private user data stored on web sites, between their own principals. We achieve this in a produc- the risk posed by compromised renderer processes, and the tion setting using Site Isolation in Google Chrome, introduc- advent of transient execution attacks like Spectre and Melt- ing OS process boundaries between web site principals. down that can leak data via microarchitectural state, it is no While Site Isolation was originally envisioned to mitigate longer safe to render documents from different web sites in exploits of bugs in the renderer process, the recent discov- the same process. In this paper, we describe our successful ery of transient execution attacks [8] like Spectre [34] and deployment of the Site Isolation architecture to all desktop Meltdown [36] raised its urgency. These attacks challenge users of Google Chrome as a mitigation for process-wide a fundamental assumption made by prior web browser ar- attacks. Site Isolation locks each renderer process to doc- chitectures: that software-based isolation can keep sensi- uments from a single site and filters certain cross-site data tive data protected within an operating system process, de- from each process. We overcame performance and compat- spite running untrustworthy code within that process. Tran- ibility challenges to adapt a production browser to this new sient execution attacks have been demonstrated to work from architecture. We find that this architecture offers the best JavaScript code [25, 34, 37], violating the web security path to protection against compromised renderer processes model without requiring any bugs in the browser. We show and same-process transient execution attacks, despite current that our long-term investment in Site Isolation also provides limitations. Our performance results indicate it is practical a necessary mitigation for these unforeseen attacks, though to deploy this level of isolation while sufficiently preserving it is not sufficient: complementary OS and hardware miti- compatibility with existing web content. Finally, we discuss gations for such attacks are also required to prevent leaks of future directions and how the current limitations of Site Iso- information from other processes or the OS kernel. lation might be addressed. To deploy Site Isolation to users, we needed to over- come numerous performance and compatibility challenges 1 Introduction not addressed by prior research prototypes [23, 62, 63, 68]. Ten years ago, web browsers went through a major architec- Locking each sandboxed renderer process to a single site ture shift to adapt to changes in their workload. Web con- greatly increases the number of processes; we present pro- tent had become much more active and complex, and mono- cess consolidation optimizations that keep memory overhead lithic browser implementations were not effective against the low while preserving responsiveness. We reduce overhead security threats of the time. Many browsers shifted to a and latency by consolidating painting and input surfaces of multi-process architecture that renders untrusted web con- contiguous same-site frames, along with parallelizing pro- tent within one or more low-privilege sandboxed processes, cess creation with network requests and carefully managing mitigating attacks that aimed to install malware by exploiting a spare process. Supporting the entirety of the web pre- a rendering engine vulnerability [43, 51, 70, 76]. sented additional compatibility challenges. Full support for Given recent changes in the security landscape, that multi- out-of-process iframes requires proxy objects and replicated process architecture no longer provides sufficient safety for state in frame trees, as well as updates to a vast number of visiting untrustworthy web content, because it does not pro- browser features. Finally, a privileged process must filter vide similar mitigation for attacks between different web sensitive cross-site data without breaking existing cross-site sites. Browsers load documents from multiple sites within JavaScript files and other subresources. We show that such the same renderer process, so many new types of attacks filtering requires a new type of confirmation sniffing and can target rendering engines to access cross-site data [5, 10, 11, protect not just HTML but also JSON and XML, beyond 33, 53]. This is increasingly common now that the most ex- prior discussions of content filtering [23, 63, 68].
USENIX Association 28th USENIX Security Symposium 1661 With these changes, the privileged browser process can In this paper, we move to a stronger threat model empha- keep most cross-site sensitive data out of a malicious docu- sizing two different types of web attackers that each aim to ment’s renderer process, making it inconsequential for a web steal data across web site boundaries. First, we consider a attacker to access and exfiltrate data from its address space. renderer exploit attacker who can discover and exploit vul- While there are a set of limitations with its current imple- nerabilities to bypass security checks or even achieve ar- mentation, we argue that Site Isolation offers the best path to bitrary code execution in the renderer process. This at- mitigating the threats posed by compromised renderer pro- tacker can disclose any data in the renderer process’s ad- cesses and transient execution attacks. dress space, as well as lie to the privileged browser process. In this paper, Section 2 introduces a new browser threat For example, they might forge an IPC message to retrieve model covering renderer exploit attackers and memory dis- sensitive data associated with another web site (e.g., cook- closure attackers, and it discusses the current limitations ies, stored passwords). These attacks imply that the privi- of Site Isolation’s protection. Section 3 presents the chal- leged browser process must validate access to all sensitive re- lenges we overcame in fundamentally re-architecting a pro- sources without trusting the renderer process. Prior work has duction browser to adopt Site Isolation, beyond prior re- shown that such attacks can be achieved by exploiting bugs search browsers. Section 4 describes our implementation, in the browser’s implementation of the Same-Origin Policy consisting of almost 450k lines of code, along with critical (SOP) [54] (known as universal cross-site scripting bugs, or optimizations that made it feasible to deploy to all desktop UXSS), with memory corruption, or with techniques such as and laptop users of Chrome. Section 5 evaluates its effective- data-only attacks [5, 10, 11, 33, 53, 63, 68]. ness against compromised renderers as well as Spectre and Second, we consider a memory disclosure attacker who Meltdown attacks. We also evaluate its practicality, finding cannot run arbitrary code or lie to the browser process, but that it incurs a total memory overhead of 9-13% in practice who can disclose arbitrary data within a renderer process’s and increases page load latency by less than 2.25%, while address space, even when the SOP would disallow it. This sufficiently preserving compatibility with actual web con- can be achieved using transient execution attacks [8] like tent. Given the severity of the new threats, Google Chrome Spectre [34] and Meltdown [36]. Researchers have shown has enabled Site Isolation by default. Section 6 looks at the specifically that JavaScript code can manipulate microar- implications for the web’s future and potential ways to ad- chitectural state to leak data from within the renderer pro- dress Site Isolation’s current limitations. We compare to re- cess [25, 34, 37].1 While less powerful than renderer exploit lated work in Section 7 and conclude in Section 8. attackers, memory disclosure attackers are not dependent on Overall, we answer several new research questions: any bugs in web browser code. Indeed, some transient exe- cution attacks rely on properties of the hardware that are un- • Which parts of a web browser’s security model can be likely to change, because speculation and other transient mi- aligned with OS-level isolation mechanisms, while pre- croarchitectural behaviors offer significant performance ben- serving compatibility with the web? efits. Because browser vendors cannot simply fix bugs to • What optimizations are needed to make process-level mitigate cases of these attacks, memory disclosure attackers isolation of web sites feasible to deploy, and what is the pose a more persistent threat to the web security model. It resulting performance overhead for real users? is thus important to reason about their capabilities separately • How well does process-level isolation of web sites up- and mitigate these attacks architecturally. grade existing security practices to protect against com- 2.1 Scope promised renderer processes? • How effectively does process-level isolation of web We are concerned with isolating sensitive web site data from sites mitigate Spectre and Meltdown attacks, and where execution contexts for other web sites within the browser. are additional mitigations needed? Execution contexts include both documents (in any frame) and workers, each of which is associated with a site princi- 2 Threat Model pal [52] and runs in a renderer process. We aim to protect many types of content and state from the attackers described We assume that a web attacker can lure a user into visit- above, including the HTML contents of documents, JSON ing a web site under the attacker’s control. Multi-process or XML data files they retrieve, state they keep within the browsers have traditionally focused on stopping web attack- browser (e.g., cookies, storage, saved passwords), and per- ers from compromising a user’s computer, by rendering un- missions they have been granted (e.g., geolocation, camera). trusted web content in sandboxed renderer processes, coor- Site Isolation is also able to strengthen some existing se- dinated by a higher-privilege browser process [51]. How- curity practices for web application code, such as upgrad- ever, current browsers allow attackers to load victim sites ing clickjacking [30] protections to be robust against com- into the same renderer process using iframes or popups, so the browser must trust security checks in the renderer process 1In some cases, transient execution attacks may access information to keep sites isolated from each other. across process or user/kernel boundaries. This is outside our threat model.
1662 28th USENIX Security Symposium USENIX Association promised renderers, as discussed in Section 5.1. Not all the process level. We advance this model in Chrome web security defenses are in scope, such as mitigations for by partitioning web content into finer-grained principals XSS [46]. that correspond to web sites. We adopt the site defi- origins 2.2 Limitations nition from [52] rather than as proposed in re- search browsers [23, 62, 63, 68]. For example, an origin For both types of attackers we consider, Site Isolation aims https://bar.foo.example.com:8000 corresponds to a site to protect as much site data as possible, while preserving https://example.com. This preserves compatibility with up compatibility. Because we isolate sites (i.e., scheme plus to 13.4% of page loads that change their origin at runtime by registry-controlled domain name [52]) rather than origins assigning to document.domain [12]. Site principals ensure (i.e., scheme-host-port tuples [54]) per Section 3.1, cross- that a document’s security principal remains constant after origin attacks within a site are not mitigated. We hope to document.domain modifications. allow some origins to opt into origin-level isolation, as dis- For each navigation in any frame, the browser process cussed in Section 6.3. computes the site from the document’s URL, determining Cross-site subresources (e.g., JavaScript, CSS, images, its security principal. This is straightforward for HTTP(S) media) are not protected, since the web allows documents URLs, though some web platform features require special to include them within an execution context. JavaScript and treatment, as we discuss in Appendix A (e.g., about:blank CSS files were already somewhat exposed to web attackers can inherit its origin and site). (e.g., via XSSI attacks that could infer their contents [26]); 3.2 Dedicated Processes the new threat model re-emphasizes not to store secrets in such files. In contrast, cross-site images and media were suf- Site Isolation requires that renderer processes can be dedi- ficiently opaque to documents before, suggesting a need to cated to documents, workers, and sensitive data from only better protect at least some such files in the future. a single site principal. In this paper, we consider only the The content filtering we describe in Section 3.5 is also case where all web renderer processes are locked to a single a best-effort approach to protect HTML, XML, and JSON site. It would also be possible for the browser to isolate only files, applying only when it can confirm the responses match some sites and leave other sites in shared renderer processes. the reported content type. This confirmation is necessary to In such a model, it is still important to limit a dedicated ren- preserve compatibility (e.g., with JavaScript files mislabeled derer process to documents and data from its own site, but it as HTML). Across all content types, we expect this filtering is also necessary to prevent a shared process from retrieving will protect most sensitive data today, but there are opportu- data from one of the isolated sites. When isolating all sites, nities to greatly improve this protection with headers or web requests for site data can be evaluated solely on the process’s platform changes [21, 71, 73], as discussed in Section 6.1. site principal and not also a list of which sites are isolated. Finally, we rely on protection domains provided by the The browser’s own components and features must be also operating system. In particular, we assume that the OS’s partitioned in a way that does not leak cross-site data. For process isolation boundary can be trusted and consider cross- example, the network stack cannot run within the renderer process and kernel attacks out of scope for this paper, though process, to protect HttpOnly cookies and so that filtering de- we discuss them further in Sections 5.2 and 6.2. cisions on cross-site data can be made before the bytes from the network enter the renderer process. Similarly, browser 3 Site Isolation Browser Architecture features must not proactively leak sensitive data (e.g., the The Site Isolation browser architecture treats each web site user’s stored credit card numbers with autofill) to untrust- as a separate security principal requiring a dedicated renderer worthy renderer processes, at least until the user indicates process. Prior production browsers used rendering engines such data should be provided to a site [49]. These additional that predated the security threats in Section 2 and were ar- constraints on browser architecture may increase the amount chitecturally incompatible with putting cross-site iframes in of logic and state in more privileged processes. This does not a different process. Prior research browsers proposed similar necessarily increase the attack surface of the trusted browser isolation but did not preserve enough compatibility to han- process if these components (e.g., network stack) can move dle the full web. In this section, we present the challenges to separate sandboxed processes, as in prior microkernel-like we overcame to make the Site Isolation architecture compat- browser architectures [23, 62]. ible with the web in its entirety. 3.3 Cross-Process Navigations 3.1 Site Principals When a document in a frame navigates from site A to site Most prior multi-process browsers, including Chrome, Edge, B, the browser process must replace the renderer process for Safari, and Firefox, did not assign site-specific security site A with one for site B. This requires maintaining state in principals to web renderer processes, and hence they did the browser process, such as session history for the tab, re- not enforce isolation boundaries between different sites at lated window references such as openers or parent frames,
USENIX Association 28th USENIX Security Symposium 1663 and tab-level session storage [74]. Due to web-visible events (a) Web Page (b) Browser Process such as beforeunload and unload and the fact that a nav- a.com/1 a.com/1 igation request might complete without creating a new doc- Document Proxy Widget ument (e.g., a download or an HTTP “204 No Content” re- A B A sponse), the browser process must coordinate with both old a.com/2 b.com/3 and new renderer processes to switch at the appropriate mo- a.com/2 b.com/3 a.com/4 Document Document Proxy Widget ment: after beforeunload, after the network response has A B A B Proxy proven to be a new document, and at the point that the new B a.com/4 process has started rendering the new page. Note that cross- Document Proxy Widget site server redirects may even require selecting a different A B A renderer process before the switch occurs. (tag">c) Renderer Process A (d) Renderer Process B Session history is particularly challenging. Each stop in the back/forward history can contain information about mul- Document Proxy tiple cross-site documents in various frames in the page, and widget it can include sensitive data for each document, such as the Document Proxy Proxy Document contents of partially-filled forms. To meet the security goals of Site Isolation, this site-specific session history state can widget only be sent to renderer processes locked to the correspond- Document Proxy ing site. Thus, the browser process must coordinate session widget history loads at a frame granularity, tracking which data to Figure 1: An example of out-of-process iframes. To render the send to each process as cross-site frames are encountered in web page shown in (a), the browser process (b) coordinates two the page being loaded. renderer processes, shown in (c) and (d). 3.4 Out-of-process iframes which we call proxies. Proxies offer cross-process support The largest and most disruptive change for Site Isolation is for the small set of cross-origin APIs that are permitted by the requirement to load cross-site iframes in a different ren- the web platform, as described in [52]. These APIs may derer process than their embedding page. Most widely-used be accessed on a frame’s window object and are used for browser rendering engines were designed and built before traversing the frame hierarchy, messaging, focusing or nav- browsers became multi-process. The shift to multi-process igating other frames, and closing previously opened win- browsers typically required some changes to these existing dows. Traversing the frame hierarchy must be done syn- engines in order to support multiple instances of them. How- chronously within the process using proxies, but interactions ever, many core assumptions remained intact, such as the between documents can be handled asynchronously by rout- ability to traverse all frames in a page for tasks like paint- ing messages. Note that all same-site frames within a frame ing, messaging, and various browser features (e.g., find-in- tree (or other reachable pages) must share a process, allow- page). Supporting out-of-process iframes is a far more intru- ing them to synchronously script each other. sive change that requires revisiting such assumptions across An example of a page including out-of-process iframes the entire browser. Meanwhile, prior research prototypes is shown in Figure 1 (a), containing three documents from that proposed this separation [23, 63, 68] did not address a.com and one from b.com, and thus requiring two separate many of the challenges in practice, such as how to ensure the renderer processes. Figure 1 (b) shows the browser process’s iframe’s document knows its position in the frame tree. This frame tree, with representations of each document annotated section describes the challenges we overcame to make out- by which site’s process they belong to, along with a set of of-process iframes functional and compatible with the web proxy objects for each frame (one for each process which platform. might reference the frame). Figure 1 (c-d) shows the corre- sponding frame trees within the two renderer processes, with Frame Tree. To support out-of-process iframes, multi- proxy objects for any documents rendered in a different pro- process browser architectures must change their general ab- cess. Note that the actual document and proxy objects live in straction level from page (containing a tree of frames) to doc- renderer processes; the corresponding browser-side objects ument (in a single frame). The browser process must track are stubs that track state and route IPC messages between which document, and thus principal, is present in each frame the browser and renderer processes. of a page, so that it can create an appropriate renderer process For example, suppose the document in a.com/2 in- and restrict its access accordingly. The cross-process naviga- vokes window.parent.frames["b"].postMessage("msg", tions described in Section 3.3 must be supported at each level "b.com"). Renderer Process A can traverse its local frame of the frame tree to allow iframes to navigate between sites. tree to find the parent frame and then its child frame named Each process must also keep a local representation of doc- “b”, which is a proxy. The renderer process will send the uments that are currently rendered in a different process, message to the corresponding ProxyA object for b.com/3 in
1664 28th USENIX Security Symposium USENIX Association the browser process. The browser process passes it to the Note that images and media from other sites can be in- current DocumentB object in this frame, which sends the cluded in a document. The Site Isolation architecture does message to the corresponding Document object in Renderer not try to exclude these from the renderer process, for mul- Process B. Similar message routing can support other tiple reasons. First, moving cross-origin image handling out cross-origin APIs, such as focus, navigation, or closing of the renderer process and preventing renderers from read- windows. ing these surfaces would require a great deal of complex- State Replication. The renderer process may need syn- ity in practice. Second, this would substantially increase the chronous access to some types of state about a frame in an- number of surfaces needed for compositing. This decision is other process, such as the frame’s current name (to find a consistent with other research browsers [23, 62, 63], includ- frame by name, as in the example above) or iframe sandbox ing Gazelle’s implementation [68]. Thus, we leave cross-site flags. As this state changes, the browser process broadcasts images and media in the renderer process and rely on servers it to all proxies for a frame across affected processes. Note to prevent unwanted inclusion, as discussed in Section 6.1. that this state should never include sensitive site-specific data Affected Features. In a broad sense, almost all browser fea- (e.g., full URLs, which may have sensitive URL parameters), tures that interact with the frame tree must be updated to only what is necessary for the web platform implementation. support out-of-process iframes. These features could tradi- Painting and Input. To preserve the Site Isolation security tionally assume that all frames of a page were in one process, model, the rendered appearance of each document cannot so a feature like find-in-page could traverse each frame in the leak to other cross-site renderer processes. Otherwise, an tree in the renderer process, looking for a string match. With attacker may be able to scrape sensitive information from out-of-process iframes, the browser process must coordinate the visible appearance of frames in other processes. Instead, the find-in-page feature, collecting partial results from each each renderer process is responsible for the layout and paint frame across multiple renderer processes. Additionally, the operations within each of its frames. These must be sent to feature must be careful to avoid leaking information to ren- a separate process for compositing at the granularity of sur- derer processes (e.g., whether there was a match in a cross- faces, to form the combined appearance of the page. The site sibling frame), and it must be robust to renderer pro- compositing process must support many types of transforms cesses that crash or become unresponsive. that are possible via CSS, without leaking surface data to a These updates are required for many features that com- cross-site renderer process. bine data across frames or that perform tasks that span multi- Often, many frames on a page come from the same site, ple frames: supporting screen readers for accessibility, com- and separate surfaces for each frame may be unnecessary. positing PDFs for printing, traversing elements across frame boundaries for focus tracking, representations of the full To reduce compositing overhead, we use a widget abstrac- 2 tion to combine contiguous same-site frames into the same page in developer tools, and many others. surface. Figure 1 shows how a.com/1 and a.com/2 can be 3.5 Cross-Origin Read Blocking rendered in the same widget and surface without requiring compositing. b.com/3 requires its own widget in Renderer Loading each site’s documents in dedicated renderer pro- Process B. Since a.com/4 is not contiguous with the other cesses is not sufficient to protect site data: there are many le- two a.com frames and its layout may depend on properties gitimate ways for web documents to request cross-site URLs assigned to it by b.com/3 (e.g., CSS filters), it has a separate within their own execution context, such as JavaScript li- widget within Renderer Process A, and its surface must be braries, CSS files, images, and media. However, it is im- composited within b.com/3’s surface. portant not to give a renderer process access to cross-site Widgets are also used for input event routing, such as URLs containing sensitive data, such as HTML documents mouse clicks and touch interactions. In most cases, the or JSON files. Otherwise, a document could access cross- compositing metadata makes it possible for the browser pro- site data by requesting such a URL from a