Privilege Separation in Browser Extensions Based on Web Workers

Transcription

1 Advanced Materials Research Submitted: ISSN: , Vols , pp Accepted: doi: / Online: Trans Tech Publications, Switzerland Privilege Separation in Browser Extensions Based on Web Workers Chunmei Yu 1,a, Jianhua Sun 2,b, Hao Chen 3,c, and Xianghua Xu 4,d 1,2,3 College of Information Science and Engineering, Hunan University, Changsha, China 4 Zhejiang Provincial Key Lab of Data Storage and Transmission Technology, Hangzhou Dianzi University, China a lantianxia@hnu.edu.cn, b jhsun@aimlab.org, c haochen@aimlab.org, Keywords: Privilege Separation, Web Workers Abstract. In this paper, we propose to use Web Workers [1], isolated parallel threads in current browser working in the background, to enforce privilege separation in chrome extensions. Our tests show that our design is applicable to most chrome extensions (those not using the jquery library) and achieves a reduction in TCB up to 77 percent for our examples. Our implementation shows that our design is efficient enough to enforce privilege separation in chrome extensions and not needs to modify the browser or learn new high-level languages. Introduction With Web applications and browser extensions becoming more and more popular, the web vulnerabilities are still pervasive [2]. The Web applications that own the elevated privileges are the main target of attackers. The Google Chrome Extension platform has recognized the necessity to enforce privilege separations in the chrome extensions. The Google Chrome Extension platform divides a chrome extension into two components: the core extension that runs in an isolated sandbox and content scripts that are in charge of interacting with the browser [4]. The permission mechanism enforces restrictions on the privileges the extension requires [7]. However, this design that needs to modify the browser and its permission mechanism is not sufficient enough to enforce privilege separation because of its coarse grained policies. Recently, the paper [3] proposes a language-based approach to isolate an application by assigning every component a minimum of privileges of a Web application, each of which forms an isolated domain. But, in this approach, it is necessary for developers to learn a new high-level language that is time consuming and can t maintain completed compatibility with legacy code. In 2012, iframes are proposed to enforce privilege separation in Web applications. But it has a shortcoming that the script code in an iframe may impact the main page s liveness, if the script code consumes the resources of the browser or goes into a dead loop [6]. In this paper, we proposed to use Web Workers to enforce privilege separation in Chrome extensions. Web Workers provide completely isolated JavaScript environment and work in the background, which can t impact the main page s liveness. In our system, we create a common privileged master and a few unprivileged workers. How many components a chrome extension can be divided is decided by the number of the extension pages, e.g., we divide an extension owning background.html, popup.html and options.html into three components. We just put all the functional JS files from an extension page into an unprivileged Web Worker and other HTML and CSS files still execute in the extension page. The workers communicate with the master with postmessage [6]. The master interposes on all the privileged calls from workers by enforcing a fine-grained policy code that is application-specific and can be modified freely by developers. We show that our proposal is practical for most existing chrome extensions. We retrofit two Google Chrome extensions to use our design. Its overhead for memory consumption is a little high, but the absolute costs are tolerable (no human perceivable latency). In our examples, the trusted All rights reserved. No part of contents of this paper may be reproduced or transmitted in any form or by any means without the written permission of Trans Tech Publications, (ID: , Pennsylvania State University, University Park, USA-10/05/16,05:20:04)

2 4676 Materials Science, Computer and Information Technology computing base (TCB) [8] reduces by up to 77 percent and no more than 18 lines of code need to change. And, there is no need for developers to learn new languages. There is a limitation to use our design. Since Web Workers can t access the DOM, the library jquery will not work in them. As a result, our design is only applicable to these chrome extensions that not using jquery. Design In this section, we describe our privilege separation architecture for chrome extensions. In our design, an extension has a common privileged master and an arbitrary number of unprivileged Web Workers [6]. The privileged master is loaded in every extension page before the extension is packaged. Each unprivileged Web Worker is created by the privileged master in each extension page and all JS files from an extension page execute in its own Web Worker. Since jquery library is invalid in a worker, our design is only applicable to those chrome extensions without using jquery. Figure 1 shows our proposed model for privilege separation. Master. The master mediates all the privileged calls from the unprivileged Web Workers. The privileged master has four components: (1) Startup Code. After the extension is loaded, the startup code begins to create a Web Worker and imports all the JS files hosted in the extension page into the worker. (2) Master Shim. When the script code in a worker makes privileged calls to the privileged master in the extension page, the master shim is in charge of all the privileged calls on behalf of the workers and returns the required results to the corresponding workers. (3) Policy Code. The policy code specifies what kinds of privileged operations the worker code can ask the master to perform. It is application-specific. The developers can add additional essential restrictions on these extensions or modify some privileges. (4) Proxy. Since the Web Workers do not have access to DOM, we have to virtualize the DOM (VDOM)[6]. The proxy is in charge of disposing the DOM modification messages from workers. Workers. Our system moves all functional JavaScript files from different components of an extension to Web Workers. Each worker consists of three components: (1) JavaScript Code. JavaScript code means the JavaScript files that render operations from the extension page, e.g., popup.js and other JavaScript libraries the page needs. (2) Worker Shim. The worker shim consists of a wrapper module. It wraps all the privileged functions. When a call is invoked, its corresponding wrapped function marshals the function as a message and posts this message to the master. On receiving respond from the master, the worker shim also deals with the execution of the callback with the results to complete the original call. (3) Monitor. Since workers have no access to the real DOM, the monitor is in charge of 1) exporting to the Web Worker a Virtual DOM (VDOM) [6], 2) listening to the VDOM modifications, 3) applying the modification events to the master. The VDOM can be implemented by Jsdom [9], a JavaScript implementation of the DOM. Besides, we also use the libraries underscore and RequireJS to complement the JavaScript functionality. The VDOM contains subtrees of the real DOM (the extension s JavaScript code decides which subtrees are used). Implementation To integrate our design into a chrome extension, before an extension is packaged, the developer needs to include the master code as a JavaScript file inside every extension pages. When the packaged extension loaded, the startup code in every page creates an unprivileged Web Worker respectively and executes the extension script code in it. In this section, we focus on the procedure of implementing a privileged call and DOM modification.

3 Advanced Materials Research Vols (1) Implementing a privileged call. When a privileged API (e.g., chrome.tabs.getselected) is called, its wrapped function begins to executes, which asks the master to perform the correct function by 1) marshaling the privileged function name and all its arguments as a message, 2) saving the privileged function s callback in Figure 1: High-level of our architecture an array, 3) sending the messages to the master, 4) waiting for respond from the master, 5) executing the saved callback with the parameters from the master. Listing 1 is the wrapped function for the chrome.tabs.getselected. On receiving a message from a Web Worker, the master shim 1) demarshals the message from the worker, 2) checks with the policy code to see if the call is allowed, 3) executes the correct function if allowed, 4) marshals the results as a message, 5) sends the message back to the worker. Listing 2 shows the master shim for the chrome.tabs.getselected. (2) Implementing a DOM modification. When the VDOM is modified, the monitor 1) serializes the events, 2) marshals it as a message, 3) sends the message to the master using postmessage. Upon receiving this message, the proxy 1) demarshals the message, 2) deserializes the modification event, 3) applies the modification event to the real DOM. Examples We apply our design to two chrome extensions to demonstrate that our architecture is efficient enough in privilege separation. In the two examples we measure (a) the reduction in TCB after using our architecture, (b) the amount of code need to be changed in order to retrofit the application, and (c) performance overheads (load latency, communication time, the interposition time by policies, and memory consumption). Table 1 lists our examples and summarizes our results. TabJump. We apply our design to a chrome extension called TabJump, which can help a user to easily access most used tabs, associated tabs, and closed tabs, and allow a user to lock the current tab in case of accidentally clicking the close button. This extension has two components: background.html and popup.html. The functionality of background.html is to get tabs information, consisting recently closed tabs, related tabs, and frequently used tabs, then send these tabs to popup.html; when a user click the TabJump button, popup.html opens, which shows all these tabs link and provide the lock feature. (1) Unbundling and Example Policy: In the original version of TabJump, popup.html receives the tabs information from background.html and allows users to open, update, or lock these tabs, but runs with full privileges of the extension. Under our design, the popup.js code runs within an unprivileged worker and the policy only gives the popup.js access to the sendmessage API to send and receive the

4 4678 Materials Science, Computer and Information Technology tabs information from the background page as well as only tabs.create, tabs.update, tabs.getselected and tabs.getallinwindow chrome APIs. PanicButton. PanicButton is a chrome extension that can be used to hide all tabs in the browser just clicking the hide button and restore them by another click. This extension has three components: Listing 1: Wrapped function for chrome.tabs.getselected Listing 2: Master shim for chrome.tabs.getselected background.html, popup.html and options.html. The functionality of background.html is to hide or restore all tabs; a user also can set a shortcut for this button and set a password to manage these hidden tabs in options.html. When a password is set, a user must enter the password in the popup page to restore these hidden tabs. (1) Unbundling and Example Policy: This extension uses options.html to set a shortcut for the hide button and enter a password in the popup.html to manage the hidden tabs. But these two pages have full privileges of this extension. In our architecture, popup.js and options.js execute in different unprivileged Web Workers, the policy only gives the popup page the privilege to call sendmessage API and the options page the privileges to call chrome.tabs.create and sendmessage APIs. Evaluation Our approach has four possible overheads: 1) latency of loading Web Workers; 2) the overhead caused by the parent s mediation on privileged APIs; 3) the overhead on each call crossing the sandbox boundary; 4) the memory consumption of the redesigned extensions. We measure the impact of each below. Latency. To measure the time overhead, we include two scripts in an extension page s different places, measuring the time elapsed between them. For example, one script is in the page s header and the other at the end of its body to measure the load latency. We perform 10 runs in each extension page, using the JavaScript s Date.now() API to collect the average time. For TabJump, the background load latency is about 319ms, and the VDOM size is 9 KB with 61ms to populate it. The average time on each call crossing the sandbox boundary is about 14ms, and with 13 lines of policy code, the average interposition time is less than 1ms. As shown in Table 1 and Table 2, without VDOM, our extension runs nearly at a local speed; even with VDOM, we do not observe any user-perceivable increase in latency. The VDOM population time is affected by its size more or less. However, unless the chrome extensions spend most of its time in DOM operations and the VDOM size is not too big, and the total overhead should be tolerable. Memory. We evaluated the memory overhead by observing the increase in memory consumption caused by creating web workers. We found that with the two extensions, the memory increase is 2.8M and 2.3M respectively. We believe that this level of overhead should be acceptable to enforce privilege separation in chrome extensions. Besides, it s up to a user to close these Web Workers after the chrome extensions exit, since it will not be automatically garbage collected.

5 Advanced Materials Research Vols Conclusion We propose a new design that uses Web Workers to partition a web application into an arbitrary number of unprivileged components. Our evaluation shows that we can apply our architecture to most chrome applications and achieve significant reduction in TCB with no more than 18 lines of change for the chrome extensions we studied. However, those extensions that use jquery library do not fit with our model. Acknowledgements This research was supported in part by the National Natural Science Foundation of China under grants and , the Program for New Century Excellent Talents in University, the open research fund of Zhejiang Provincial Key Lab of Data Storage and Transmission Technology, Hangzhou Dianzi University(No ) Reference [1] HTML5 living standard. [2] Google Inc., Google chrome webstore. [3] A. Krishnamurthy, A. Mettler, and D. Wagner. Fine-Grained Privilege Separation for Web Applications. In Proceedings of the International Conference on World Wide Web, pages , [4] A. Barth, C. Jackson, C. Reis, and T. G. C.Team, The security architecture of the chromium browser, [5] Privilege Separation in HTML5 Applications, Devdatta Akhawe, Dawn Song, Prateek Saxena, [6] TreeHouse: JavaScript sandboxes to help Web developers help themselves, Lon Ingram, Michael Walfish, [7] N. Carlini, A. P. Felt, and D. Wagner, An evaluation of the google chrome extension security architecture, in Proceedings of the 21st USENIX Conference on Security, [8] [9]

6 Materials Science, Computer and Information Technology / Privilege Separation in Browser Extensions Based on Web Workers /