Protecting Browsers from Extension Vulnerabilities
Adam Barth Adrienne Porter Felt Prateek Saxena Aaron Boodman
Electrical Engineering and Computer Sciences University of California at Berkeley
Technical Report No. UCB/EECS-2009-185 http://www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-185.html
December 18, 2009 Copyright © 2009, by the author(s). All rights reserved.
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission.
Acknowledgement
We would like to thank Nick Baum, Erik Kay, Collin Jackson, Matt Perry, Dawn Song, David Wagner, and the Google Chrome Team. This work is partially supported by the Air Force Office of Scientific Research under MURI Grant No. 22178970-4170. Protecting Browsers from Extension Vulnerabilities
Adam Barth, Adrienne Porter Felt, Prateek Saxena Aaron Boodman University of California, Berkeley Google, Inc. {abarth, afelt, prateeks}@eecs.berkeley.edu [email protected]
Abstract browser’s full privileges. If an attacker can exploit an ex- tension vulnerability, the attacker can usurp the extension’s Browser extensions are remarkably popular, with one in broad privileges and install malware on the user’s machine. three Firefox users running at least one extension. Although At this year’s DEFCON, Liverani and Freeman presented well-intentioned, extension developers are often not security attacks against a number of popular Firefox extensions [23]. experts and write buggy code that can be exploited by ma- In one example, if the user dragged an image from a mali- licious web site operators. In the Firefox extension system, cious web page into the extension, the web site operator these exploits are dangerous because extensions run with could install a remote desktop server on the user’s machine the user’s full privileges and can read and write arbitrary and take control of the user’s mouse and keyboard. files and launch new processes. In this paper, we analyze These attacks raise the question of whether browser ex- 25 popular Firefox extensions and find that 88% of these tensions require such a high level of privilege. To investi- extensions need less than the full set of available privileges. gate this question, we examine 25 popular Firefox exten- Additionally, we find that 76% of these extensions use un- sions to determine how much privilege each one requires. necessarily powerful APIs, making it difficult to reduce their We find that only 3 of the 25 extensions require full sys- privileges. We propose a new browser extension system that tem access. The remainder are over-privileged, needlessly improves security by using least privilege, privilege separa- increasing the severity of extension vulnerabilities. An ex- tion, and strong isolation. Our system limits the misdeeds tension system that narrows this privilege gap would reduce an attacker can perform through an extension vulnerabil- the severity of extension exploits, but the Firefox extension ity. Our design has been adopted as the Google Chrome platform does not provide sufficiently fine-grained privi- extension system. leges. For example, many extensions store settings with an interface that can read and write arbitrary files. We propose a new extension system, built with security 1 Introduction in mind. In particular, we aim to protect users from benign- but-buggy extensions by designing least privilege, privilege separation, and strong isolation into our extension system. Web browser extensions are phenomenally popular: Instead of running with the user’s full privileges, extensions roughly one third of Firefox users have at least one in our system are limited to a set of privileges chosen at browser extension [22]. Browser extensions modify the install time. If an extension later becomes compromised, core browser user experience by changing the browser’s the extension will be unable to increase this set of privi- user interface and interacting with web sites. For exam- leges. In particular, our case studies of Firefox extensions ple, the Skype browser extension rewrites phone numbers suggest that most extensions do not require the privilege to found in web pages into hyperlinks that launch the epony- execute arbitrary code; consequently, the privilege to exe- mous IP-telephony application [5]. Although there have cute arbitrary code will often be unavailable to an attacker been several recent proposals for new web browser archi- who compromises an extension in our system. tectures [18, 11, 32], little attention has been paid to the In addition to limiting the overall privileges of each ex- architecture of browser extension systems. tension, our system further reduces the attack surface of Many extensions interact extensively with arbitrary web extensions by forcing developers to divide their extensions pages, creating a large attack surface that attackers can into three components: content scripts, an extension core, scour for vulnerabilities. In this paper, we focus on benign- and a native binary (see Figure 1): but-buggy extensions. Most extensions are not written by security experts, and vulnerabilities in benign extensions • Each content script has direct access to the DOM of are worrisome because Firefox extensions run with the a single web page and is thereby exposed to poten-
1 Attacker
Figure 1. Extensions are divided into three components, each with progressively more privileges and less exposure to malicious web content.
tially malicious input. However, content scripts have Our extension system design has been adopted by no other privileges except for the ability to send mes- Google Chrome and is available in Google Chrome 4. Al- sages to the extension core. though it is difficult to predict how developers will use the extension system, we believe that this architecture will pro- • The extension core contains the bulk of the extension vide a solid foundation for building more secure extensions. privileges, but the extension core can only interact with web content via XMLHttpRequest and content scripts. Even the extension core does not have direct 2 Attacks on Extensions access to the host machine. A browser extension is a third-party software module • An extension can optionally include a native binary that extends the functionality of a web browser, letting users that can access the host machine with the user’s full customize their browsing experience. Because extensions privileges. The native binary interacts with the ex- interact directly with untrusted web content, extensions are tension core via the standard NPAPI interface used by at risk of attack from malicious web site operators and ac- Flash and other browser plug-ins. tive network attackers. In this section, we present a generic To gain the user’s full privileges, an attacker would need threat model for extension security that applies to both the to convince the extension to forward malicious input from Firefox extension system and the new extension system we the content script to the extension core and from the exten- introduce in this paper. We then focus our attention on the sion core to the native binary, where the input would need Firefox extension system, providing background material to exploit a vulnerability. We argue that exploiting such a and examples of real attacks. multi-layer vulnerability is more difficult than exploiting a simple cross-site scripting hole in a Firefox extension. 2.1 Threat Model Finally, the different components of an extension are iso- lated from each other by strong protection boundaries: each We focus on benign-but-buggy extensions: we assume component runs in a separate operating system process. The the extension developer is well-intentioned but not a secu- content script and the extension core run in sandboxed pro- rity expert. We assume attacker attempts to corrupt the ex- cesses that cannot use most operating system services. As tension and usurp its privileges. For example, the attacker a first layer of defense, the content script is isolated from might be able to install malware on the user’s machine if the its associated web page by running in a separate JavaScript extension has arbitrary file access. We assume the attacker heap. Although both the content script and the web page is unable to entice the user into downloading or running na- have access to the same underlying DOM, the two never ex- tive executables. We further assume the browser itself is change JavaScript pointers, helping prevent JavaScript ca- vulnerability-free, letting us focus on the additional attack pability leaks [12]. surface provided by extensions.
2 We consider two related threat models: a web attacker • Replacing Native APIs. A malicious web page can and an active network attacker. The web attacker controls a confuse (and ultimately exploit) a browser extension web site, canonically https://attacker.com/, that by replacing native DOM APIs with methods of its the user visits. (Note that we do not assume that the user own definition. These fake methods might superfi- confuses the attacker’s web site with another web site.) Typ- cially behave like the native methods [9] and trick ically, the attacker attempts to corrupt an extension when the an extension into performing some misdeed. To extension interacts with the attacker’s web site. In addition help mitigate this class of attack, Firefox automati- to the abilities of a web attacker, an active network attacker cally wraps references to untrusted objects with an can intercept, modify, and inject network traffic (e.g., HTTP XPCNativeWrapper. An XPCNativeWrapper responses). The active network attacker threat model is ap- is analogous to X-ray goggles: viewing a JavaScript propriate, e.g., for a wireless network in a coffee shop. object through an XPCNativeWrapper shows the underlying native object, ignoring any modifications made by the page’s JavaScript. However, this security Plug-ins. In this paper, we focus on browser extensions, mechanism has had a long history of implementation which differ from browser plug-ins. Plug-ins render specific bugs [4, 3, 1]. Recent work has demonstrated that these media types (such as PDF and Flash) or expose additional bugs are exploitable in some extensions [23]. APIs to web content (such as the Gears APIs). Plug-ins are requested explicitly by web sites, usually by loading con- • JavaScript Capability Leaks. JavaScript capability tent with a specific MIME type. By way of contrast, ex- leaks [12] are another avenue for exploiting exten- tensions interact with web pages without their explicit con- sions. If an extension leaks one of its own objects to sent. Although plug-in security is an important area of re- a malicious web page, the attacker can often access search [18, 17], securing browser extensions requires differ- other JavaScript objects, including powerful extension ent techniques. APIs. For example, an early version of Greasemonkey exposed a privileged version of XMLHttpRequest 2.2 Exploiting Firefox Extensions to every web page [33], letting attackers circumvent the browser’s same-origin policy by issuing HTTP re- In Firefox, browser extensions run with the same privi- quests with the user’s cookies to arbitrary web sites leges as the browser itself. Firefox extensions have full ac- and reading back the responses. cess to browser internals and the user’s operating system. • Mixed Content. An active network attacker can con- Extensions can change the functionality of the browser, trol content loaded via HTTP. The most severe form modify the behavior of web sites, run arbitrary code, and of this attack occurs when a browser extension loads access the file system. Firefox extensions combine two dan- a script over HTTP and runs it. The attacker can re- gerous qualities: high privilege and rich interaction with un- place this script and hijack the extension’s privileges trusted web content. Taken together, these qualities risk ex- to install malware. A similar, but less powerful, attack posing powerful privileges to attackers. We describe four occurs when an extension injects an HTTP script into classes of attacks against browser extensions and the rele- an HTTPS page. For example, we discovered that an vant mitigations provided by the Firefox extension system: extension [6] injects an HTTP script into the HTTPS • Cross-Site Scripting. Extension cross-site script- version of Gmail. (We reported this vulnerability to ing (XSS) vulnerabilities result from interacting di- the developers of the extension on August 12, 2009, rectly with untrusted web content. For example, if an and the developers released a fixed version that oper- extension uses eval or document.write without ates only on the non-HTTPS version of Gmail.) sanitizing the input, the attacker might be able to in- Even though we might be able to design defenses for each ject a script into the extension. In one recent exam- of these attack classes, we argue that the underlying issue is ple [23], a popular RSS aggregation extension evalu- that Firefox extensions interact directly with untrusted con- ated data from the
3 !"#$%&'( /012* 6470( 3* )( 8( +#,-* 345( .* )( /012( *#+,( !"#$%&' )( -.( ()*
(a) Most powerful behavior. (b) Most powerful interface.
Figure 2. The chart on the left shows the severity ratings of the most dangerous behaviors exhibited by each extension. The chart on the right shows the security ratings of the extension interfaces used to implement these behaviors.
each needs to implement its features. In addition to pre- source code. (This methodology under-approximates the set senting our case studies, we also present an algorithm for of interfaces.) We then manually correlated the interfaces finding methods in the Firefox extension API that lead from with the extensions’ functionality. This process could not a less-privileged interface to a more-privileged interface. be automated because understanding high-level functional- ity requires human judgement. 3.1 Case Studies To compare the set of interfaces with extension func- tionality, we assigned one of five ratings (critical, high, We review 25 extensions manually to determine their medium, low, and none) to each interface and functional- privilege requirements: ity. These ratings are based on the Firefox Security Severity Ratings [8]: 1. We analyze the behavior of an extension to determine • Critical: Can run arbitrary code on the user’s system how much privilege an extension needs to realize its (e.g., arbitrary file access) functionality, letting us compare its required privileges to its actual privileges. • High: Can access site-specific confidential informa- tion (e.g., cookies and password) or the Document Ob- 2. We analyze the implementation of an extension to de- ject Model (DOM) of all web pages termine how much power the extension receives, given the set of interfaces it uses to realize its functionality. • Medium: Can access private user data (e.g., recent his- This lets us evaluate how much we could reduce its tory) or the DOM of specific web pages privileges if we limited access to interfaces. • Low: Can annoy the user We find that most extensions do not require arbitrary file • None: No security privileges (e.g., a string) or privi- system access (the most powerful privilege), meaning that leges limited to the extension itself most extensions are over-privileged. We also find that ex- tensions commonly use powerful interfaces to accomplish simple tasks because the Firefox APIs are coarse-grained. Results. Of the 25 subject extensions, only 3 require criti- cal privileges (see Figure 2(a)). Therefore, 22 of the subject extensions are over-privileged because all extensions have Methodology. We randomly selected two extensions the privilege to perform critical tasks. Despite the fact that from each of the 13 categories in the “recommended” sec- only 3 need critical privileges, 19 use a critical-rated in- tion of the Firefox Add-on directory. (See Appendix A for terface (see Figure 2(b)). An additional 3 use high-rated a list.) We excluded one of the selected extensions because interfaces despite needing only medium or less privileges, it was distributed only as a binary. We verified that the 25 meaning that a total of 19 extensions use interfaces that have subject extensions were also highly ranked in the “popu- broader privileges than they require. Figure 3 shows the de- lar” directory. To determine the extensions’ functionality, tailed results. We summarize these results below: we ran each extension and manually exercised its user in- terface. We also located usage of the extension system API • Three extensions, all download managers, require the by searching for explicit interface names in the extensions’ ability to create new processes. (These are the only
4 Behavior Interface Disparity? Frequency Process launching (C) Process launching (C) No 3 (12%) User chooses a file (N) Arbitrary file access (C) Yes 11 (44%) Extension-specific files (N) Arbitrary file access (C) Yes 10 (40%) Extension-specific SQLite (N) Arbitrary SQLite access (H) Yes 3 (12%) Arbitrary network access (H) Arbitrary network access (H) No 8 (40%) Specific domain access (M) Arbitrary network access (H) Yes 2 (8%) Arbitrary DOM access (H) Arbitrary DOM access (H) No 9 (36%) Page for display only (L) Arbitrary DOM access (H) Yes 3 (12%) DOM of specific sites (M) Arbitrary DOM access (H) Yes 2 (8%) Highlighted text/images (L) Arbitrary DOM access (H) Yes 2 (8%) Password, login managers (H) Password, login managers (H) No 3 (12%) Cookie manager (H) Cookie manager (H) No 2 (8%) Same-extension prefs (N) Browser & all ext prefs (H) Yes 21 (84%) Language preferences (M) Browser & all ext prefs (H) Yes 1 (4%)
Figure 3. The frequency of security-relevant behaviors. The security rating of each behavior is ab- breviated in parentheses. If the interface’s privilege is greater than the required behavioral privilege, there is a disparity.
three extensions that actually require critical privi- can reduce the privileges of these extensions without im- leges.) One extension converts file types using system pacting functionality. utilities, another runs a user-supplied virus scanner on Unfortunately, reducing the privileges of extensions in downloaded files, and the third launches a new process the Firefox extensions system is difficult because the Fire- to use the operating system’s shutdown command. fox extension API bundles many privileges into a single interface. This is evidenced by the 19 extensions that use • None of the extensions we studied require arbitrary file excessively powerful interfaces: 16 use critical-rated in- access. Several extensions access files selected by a terfaces and 3 use high-rated interfaces without needing file open dialog, and most use files to store extension- that level of privilege. For example, most extensions use local data. The download managers interact with files the preference service to store extension-local preferences. as they are downloaded. This service can also change browser-wide preferences and preferences belonging to other extensions. • 17 extensions require network access (e.g., observing We identified the file system interface as a common point network data) and/or web page access (e.g., manipu- of excessive privileges. Most extensions use the file system lating a page’s DOM). 10 require network access and interface, which can read and write arbitrary files. These 11 require access to web pages. Of the 10 extensions extensions could make use of lower-privilege file storage that require network access, 2 require access only to a interfaces if such interfaces existed. For example, 11 of the specific set of origins. extensions could be limited to files selected by the user via a file open dialog (analogous to the HTML file upload con- • Nearly all of the extensions require access to an trol), and 10 extensions could be limited to an extension- extension-local preference store to persist their own local persistent store (like the HTML 5 localStorage preferences, but only one changes global browser pref- API) or an extension-specific directory. The download man- erences (to switch languages). agers could also be limited to the downloads folder.
Discussion. Although every Firefox extension runs with 3.2 The Security Lattice the user’s full privileges, only three of the extensions we an- alyze actually require such a high level of privilege. The re- Even if a developer explicitly requests only a small num- maining 22 extensions exhibit a privilege gap: they run with ber of interfaces, other interfaces could be reachable from more privileges than required. Moreover, none of the sub- that set. For example, a developer might request access ject extensions require arbitrary file access and only 70% to a low-type object with a method that returns a critical- require network or web page access. The extension system type object; even though the developer has not asked for the
5 η η ` ρ ,→ α α.subtype(β) ` ρ ,→ α α.method(β) SUBTYPING METHOD ` ρ ,→η β ` ρ ,→η β
α.getter(β) α.setter(β) GETTER SETTER α.method(1 → β) α.method(β → 1)
TYPE FORGERY ` ρ ,→ρ α
` ρ ,→η α → β ` ρ ,→γ α ` η ,→δ β RETURN ` ρ ,→δ β ` ρ ,→η α → β ` ρ ,→γ α ` η ,→δ β PARAMETER ` η ,→γ α
Figure 4. Inference rules for reachability in a type system with type forgery, such as the Firefox extension API.
critical-type object, it is available. We consider this a form input parameters in the implementation. For example, type of privilege escalation. To fully limit the privilege levels of foo has a method that accepts type bar as a parameter. extensions, we must control these escalation points, either Type bar has a method getFile that returns a file type. by adding a reference monitor (e.g., to implement an access We do not know whether an implementation of foo actu- control approach) or by taming the interface (e.g., to imple- ally ever calls bar.getFile, but we know it is possible. ment an object-capability approach). We analyze a subset of the Firefox extension API to find these escalation points. In Firefox, extensions and internal browser components Deductive System. Our deductive system (see Figure 4) use the same interfaces (known as XPCOM interfaces). computes which additional interfaces a principal (the These strictly typed interfaces are defined in a CORBA- browser or an extension) can obtain from one interface. like Interface Description Language (IDL). We analyzed Along with the interface name, the rules track which princi- the XPCOM interfaces from Firefox 3.5 by adding a Dat- pal implements each concrete instance of the interface. We alog back-end to the Firefox IDL compiler. By default, write ρ ,→η α when principal ρ has a reference to an in- these interfaces are implemented internally by the browser. terface α implemented by principal η. The deduction rules However, extensions can (and do) replace these implemen- then describe various ways a reference to one interface can tations. For example, the SafeCache [21] browser extension lead to a reference to another interface. For example, if ρ replaces the HTTP cache. Regardless of the implementation possesses both a method of type α → β implemented by of an XPCOM interface, the browser enforces the return and η and an object with interface α implemented by γ, then parameter types declared in the interface description. ρ can give the α object to η by calling the method. After- We analyze the API for escalation points by organizing wards, η will have a reference to an object with interface α the XPCOM interfaces into a security lattice. We manu- implemented by δ. ally label the severity of 613 interfaces (of 1582 total), in- One subtle rule in the deductive system is the type cluding all the interfaces used by the subject extensions. forgery rule. This rule states that every principal can cre- We then automatically compute when an extension with a ate an object that implements an arbitrary interface. This reference to one interface might be able to obtain a ref- rule is appropriate for XPCOM (and, in fact, most CORBA- erence to another interface by deductive inference on the like component systems) because an extension can create a types used in the interfaces. Our deductive system is an JavaScript object that implements an XPCOM interface by over-approximation because we do not consider the actual implementing the requisite methods and announcing sup- implementation of the interfaces. Deductions based on the port in its queryInterface method. This technique is handling of input parameters might be overly conservative useful to attacks because an attacker can use a “forged” ob- because it is not known which methods are called on the ject to call a method the attacker could not call otherwise.
6 the extension system is based on least privilege, privilege separation, and strong isolation.
4.1 Least Privilege
Instead of running with the user’s full privileges, exten- sions run with a restricted set of privileges. The browser grants an extension access only to those privileges explic- itly requested in the extension’s manifest. By requiring ex- tensions to declare their privileges at install time, an attacker who compromises an extension is limited to these privileges at runtime. For example, consider the manifest for the sam- ple Gmail Checker extension [13]:
{ Figure 5. The Firefox extension API reacha- "name": "Google Mail Checker", bility graph, from our deductive system. Up- "description": "Displays the number of unread ward edges could lead to privilege escalation. messages...", "version": "1.2", "background_page": "background.html", "permissions": [ "tabs", Reachability. We computed the security lattice for the "http://*.google.com/", Firefox extension interfaces by implementing our rules in "https://*.google.com/" Datalog. We add an edge from one interface to another if ], our deductive system computes that a reference to an object "browser_action": { "default_title": "" with the first interface implemented by one principal could }, lead to an object with the second interface implemented by "icons": { the same principal. Notice that the type forgery rule permits "128": "icon_128.png" } us to reason about each interface individually instead of re- } quiring us to build a lattice over sets of interfaces. Figure 5 summarizes the lattice by coalescing all the interfaces with In the example, Gmail Checker needs access to subdomains the same security rating into a single vertex and contracting of google.com and the tabs API. An extension can re- the unlabeled interfaces. quest a number of different privileges in its manifest: Of the 2920 edges in the lattice, 147 edges go “up” the lattice. These upward edges represent potential escalation • Execute Arbitrary Code. Although our case study points that make reducing the privilege of extensions diffi- suggests that a majority of extensions do not require cult. Because our analysis is an over-approximation, some the privilege to execute arbitrary code, some exten- of these edges might not actually be exploitable given the sions do require this privilege. To request the privilege Firefox implementation of the extension interfaces. How- to execute arbitrary code, an extension lists a native ever, even these edges might become exploitable if an exten- binary in its manifest. sion replaces the built-in implementation of the relevant in- terface. To retrofit security onto the Firefox extension API, • Web Site Access. Extensions can also request the we recommend preventing privilege escalation by removing privilege to interact with web sites. Instead of receiv- these edges, either by adding runtime access control checks ing access to all web sites, extensions designate which or by taming the interfaces at design time. When designing web sites they would like to access by origin. For ex- a new extension system, we suggest not introducing escala- ample, Gmail Checker requests access to subdomains tion points into the security lattice. of Google by listing http://*.google.com and https://*.google.com in its manifest. If the extension were later compromised, the at- 4 Google Chrome Extension System tacker would not have the privilege to access https://bank.com. In this section, we describe and evaluate the security ar- chitecture of the Google Chrome extension system. We fo- • API Access. In addition to the usual web platform cus on the aspects of the design related to protecting users APIs, extensions can also request access to extension from benign-but-buggy extensions. The security model for APIs, which are grouped according to functionality.
7 Behavior Interface Disparity? User chooses a file (N) User chooses a file (N) No Extension-specific files (N) HTML5 storage (N) No Extension-specific SQLite (N) HTML5 storage (N) No Specific-domain network access (M) Restricted domains (M) No Page for display only (L) Page for display only (L) No DOM of specific sites (M) Restricted domains (M) No Highlighted text/images (L) Gleam API (L) No Same-extension prefs (N) HTML5 storage (N) No Language preferences (M) Browser settings (M) No
Figure 6. The proposed Google Chrome extension interfaces closely match the privileges required by the 25 extensions in our case study.
For example, the extension system contains an API ecutable. An attacker who can trick a user into installing group called tabs for interacting with the browser’s a malicious extension this way can likely already trick the tab strip (creating tabs, moving tabs, etc.). An ex- user into running an arbitrary executable, giving the attacker tension is granted access to an API group only if that little additional leverage. group appears in the extension’s manifest. The API groups closely match the privileges needed 4.2 Privilege Separation by the extensions we studied in Section 3.1. Figure 6 shows how those extensions could implement their To make it more difficult for a malicious web site oper- functionality using the extension APIs. For example, ator to usurp an extension’s privileges, the extension plat- an extension that requires access only to user-selected form forces developers to divide their extensions into mul- files can use the element, tiple components: content scripts, the extension core, and a which grants the extension access to a file chosen by native binary (see Figure 1): the user (and not to a mutable file handle). • Content Scripts. Content scripts let extensions inter- Without additional encouragement, developers are likely to act directly with untrusted web content. If the manifest request the maximum possible privileges for their exten- limits the extension’s access to origins, the browser sions, reducing the benefits of least privilege. To encour- blocks the extension from injecting content scripts into age developers to request the minimum required privileges, unauthorized origins. Each content script, written in we alter the user experience for installing an extension from JavaScript, has direct access to the DOM of a single the Google-controlled extension gallery based on the maxi- web page via the standard DOM APIs. Content scripts mum privilege level the extension requests. The most dan- do not have access to the powerful extension APIs pro- gerous class of extensions (extensions with the privilege vided by the browser. The only other privilege granted to execute arbitrary code) are not permitted in the gallery to content scripts is the privilege to send JSON [2] unless the developer signs a contract with Google. An- messages to the extension core via a postMessage- other approach is to review extensions manually, as in the like API. addons.mozilla.org gallery. In this approach, the manifests make it easier for reviewers to prioritize reviews • Extension Core. The extension core, written in of low-privilege extensions. This incentivizes developers to HTML and JavaScript, controls the extension’s user request fewer privileges to reduce review latency. Whether interface (e.g., browser actions, pop-ups) and has ac- these incentives are sufficient to encourage least privilege cess to the extension APIs declared in the extension’s will depend largely on whether developers can gain more manifest. The extension core contains the majority of exposure for their extensions by appearing in the gallery the extension’s privileges, but it is insulated from di- sooner or more prominently. rect interaction with untrusted web content. To interact Extensions can also be installed from arbitrary web sites. with untrusted content, the extension core can either This install experience is different from installing an exten- (1) communicate with a content script or (2) issue an sion from the gallery. When installing an extension from XMLHttpRequest. Both of these mechanisms re- outside the gallery, the user experience is the same as the quire the extension author to take explicit action and user experience for downloading and running a native ex- restrict the interaction to plain data.
8 • Native Binary. Only native binaries can run arbitrary URL. Placing the extension’s public key in its URL frees the code or access arbitrary files. To gain these privileges, extension system from depending on a central naming au- the extension developer must supply a native Netscape thority (like a public-key infrastructure or DNS), reducing Plug-in API (NPAPI) binary. For example, on Win- the attack surface of the platform and simplifying extension dows such a binary consists of a dynamically linked signing. By using this approach, we can reuse the web’s library (DLL) with certain entry points. By default, same-origin machinery to isolate extensions from browser the native binary can interact only with the extension internals, web pages, and each other. core (e.g., not with content scripts). Furthermore, the This approach to extension identity also makes updating interaction is typically limited to the interfaces defined extensions easy. If the browser encounters a newer exten- when the native binary was compiled, but, of course, sion package signed with the same public key, the browser the native binary can re-compile itself because it can can replace the installed version of the extension (unless the run arbitrary code. Similarly, the manifest lets devel- new manifest requests critical privileges and changes the in- opers expose their native binaries to web pages be- stall experience). When the browser reloads the extension, cause there are no technical means for stopping an ex- the updated version inhabits the same security context as tension that can run arbitrary code from installing a the old version, analogous to re-visiting a web site. In par- regular browser plug-in. ticular, the updated extension still has access to its previous persistent state because localStorage is segregated by Content scripts, which have the largest attack surface, do origin and its origin remains the same. not have a direct channel to the component with critical privileges. By dividing the extension’s privileges among Process Isolation. Each component of the extension runs three components, the extension system makes it harder for in a different process. The extension core and the native bi- an attacker to exploit the user’s machine. To run arbitrary nary each receive dedicated processes. Content scripts run code, the attacker first convinces the extension’s content in the same process as their associated web pages. This pro- script to forward malicious input to the extension core. The cess isolation has two benefits: it defends against browser attacker then convinces the extension core to forward the errors and low-level exploits. Process isolation helps pro- malicious input to the native binary (assuming one even ex- tect the extension core from browser implementation er- ists). Finally, the attacker exploits a vulnerability in the na- rors, such as cross-origin JavaScript capability leaks [12], tive binary. because JavaScript objects cannot leak from one process to another. Process isolation also defends against low-level 4.3 Isolation Mechanisms exploits in the browser. For example, if a malicious web site operator manages to corrupt the renderer process [11] The extension system uses three mechanisms to isolate (e.g., via a buffer overflow), the attacker will not be granted extension components from each other and from web con- access to the extension APIs because the extension core re- tent. First, we leverage the same-origin web sandbox by sides in another process. running the extension core in a unique origin designated by a public key. Second, we run the extension core and the na- Isolated Worlds. We provide an additional layer of isola- tive binaries in their own processes. Finally, content scripts tion between the content script and the untrusted web site’s run in a separate JavaScript heap from untrusted web con- JavaScript environment by running the content script in an tent. isolated world. Instead of accessing the underlying DOM data structures via the same JavaScript objects used by the Origin. In the web platform, the authority of a script is page, each content script accesses the DOM with its “own” derived from its origin (in particular, the scheme, host, JavaScript objects. Content scripts and web pages therefore and port of the URL from which the browser obtained the never exchange JavaScript pointers, making it more difficult script). However, extension scripts are not loaded from for a malicious web page to confuse the content script (e.g., the network; extensions are stored in the user’s file system. with a JavaScript rootkit [9]). Consequently, extensions do not have an origin in the usual This design changes the normal one-to-one relation be- sense. We assign an “origin” to an extension by including a tween DOM implementation objects and their JavaScript public key in the extension’s URL as follows: representations (see Figure 7) into a one-to-many rela- chrome-extension:// tion (see Figure 8). For example, both the page and the ilpnegfhimflflifcnmgpeihglhedbnn/ content script have a global variable named document, but these variables refer to two distinct JavaScript objects. When loading an extension, the browser verifies that the Consistency is still maintained: when either script calls a extension package is “self-signed” by the public key in its DOM method, such as appendChild, both objects are
9 To select the correct world with reasonable assurance, we DOM (C++) JavaScript (V8) cache a reference to the appropriate world on the function object itself at the time the callback is registered.
4.4 Performance
Separating extensions into components could potentially add overhead to operations that involve multiple compo- Figure 7. The normal one-to-one relation nents. For example, if a content script needs to use privi- between DOM implementation objects and leges held by the extension core, the content script needs to JavaScript representations. send a message to the core process instead of simply calling a function in its own address space. Similarly, DOM access from content scripts requires crossing from the extension’s isolated world to the page’s world, incurring an additional JavaScript (V8) hash table lookup on some execution paths. W1 (Page) To evaluate the run-time overhead of inter-process com- munication, we measured the round-trip latency for send- ing a message from a content script to the extension core and back in Google Chrome 4.0.249.22 on Mac OS X. We observe an average round-trip latency of 0.8 ms (n = 100, DOM (C++) W2 (Extension 1) σ = 0.0079 ms), where each trial is the average of 1000 inter-process round-trips. Of course, an extension incurs this added latency only for operations that require coordi- nation between multiple components. For example, an ex- tension that adds additional EXIF metadata to Flickr [27] in-
W3 (Extension 2) curs this overhead once per page load to issue a cross-origin XMLHttpRequest, increasing the load time by an unnotice- able 0.8 ms. To evaluate the run-time overhead of the isolated words mechanism, we ran a DOM core performance bench- mark [19] in Chromium 4.0.266.0 on Mac OS X. The benchmark measures the total speed of a set of append, Figure 8. The one-to-many relation caused by prepend, insert, index, and remove DOM operations. In the running content scripts in isolated worlds. main world, the benchmark required an average of 231 ms (n = 100, σ = 5.46 ms) to complete. When run in an isolated world, the benchmark took an average of 309 ms (n = 100, σ = 6.33 ms). The use of isolated worlds adds updated to reflect the modified document tree. However, 33.3% to DOM access time but nothing to layout and ren- when a script modifies a non-standard DOM property, such dering time. as document.foo, the modification is not reflected in the other object. These rules help maintain the invariant that JavaScript objects (i.e., non-primitive values) are never 5 Related Work transmitted between worlds. The standard one-to-one relation is implemented using a In addition to the Firefox extension system we analyze hash table keyed by DOM implementation object (depicted in this paper, Firefox has a second, experimental extension as black rectangles in the figures). For isolated worlds, system: Jetpack [26]. Similar to the extension system we we create a hash table for each world and choose which propose, Jetpack exposes browser functionality via narrow hash table to use based on the currently executing world. interfaces. Currently, however, each Jetpack extension runs When entering the JavaScript virtual machine (e.g., when with the user’s full privileges and has access to the complete invoking a callback function registered via setTimeout), Firefox extension API. As Jetpack matures, we expect the the browser must start executing the function in the proper Firefox developers to restrict the privileges of Jetpack ex- world. If the browser executes the function in the wrong tensions, but the designers of Jetpack have chosen to focus world, we risk leaking a JavaScript pointer between worlds. first on usability and generativity [28].
10 Internet Explorer has a combined plug-in and extension 6 Conclusion system known as Browser Helper Object (BHO) modules. For example, the Yahoo Toolbar for Internet Explorer is im- Browser extensions are often not written by security ex- plemented as a BHO. These extensions are written in native perts, and many extensions contain security vulnerabilities. code and have direct access to the win32 API. If a BHO Every cross-site scripting vulnerability in a Firefox exten- has a vulnerability (such as a buffer overflow), a malicious sion is an avenue for malicious web site operators to install web site can issue arbitrary win32 API calls by exploiting malware onto the user’s machine because Firefox exten- the vulnerability. Recent versions of Internet Explorer run sions run with the user’s full privileges. To evaluate whether these BHOs in “protected mode,” [25] reducing their priv- extensions actually require such a high level of privilege to ileges. However, a compromised BHO still has full access implement their feature set, we analyze 25 “recommended” to web pages (including passwords and cookie) and read extensions from the Firefox extension gallery. We find that access to the file system. the majority of these extensions do not require full privi- One recent paper [24] considers limiting the privileges leges. However, reducing the privileges of existing Firefox of Firefox extensions. They propose a mechanism for sand- extensions is difficult because many Firefox APIs are more boxing extensions by intercepting various events in the powerful than required to implement extension features. XPCOM object marshaling layer, incurring a performance Although one could imagine restructuring the Firefox overhead of 19% for a particular policy. Unlike our work, extension interface, we instead recommend building a new this paper focuses entirely on mechanism, and the authors extension platform with security in mind. In our proposed do not determine which policies their mechanism ought to system, extensions enumerate which privileges they desire enforce. We could imagine reducing the privileges of Fire- at install-time and are limited to those privileges at runtime. fox extensions by using this mechanism to restrict extension If an extension does not include a native binary (which most behavior at the escalation points we identify in Section 3.2. do not require), then an attacker who compromises the ex- A number of papers [15, 34, 7, 16, 30] consider the prob- tension will not gain the privilege to run arbitrary code. lem of running native plug-in code securely using fault iso- In addition to least privilege, we separate privileges by lation and system call interposition. These techniques fo- dividing extensions into three components: content scripts, cus on isolating untrusted native code, whereas we focus the extension core, and a native binary. Content scripts are on code written in JavaScript, letting us use the standard exposed directly to web content but have few privileges. same-origin JavaScript sandbox. We are chiefly concerned Native binaries are powerful but (by default) have no direct with the privileges afforded to extensions via explicit APIs, contact with web content. The three components interact a topic that has not been studied in much detail. Their via narrow interfaces, reducing the attack surface for the techniques for plug-in confinement are complimentary to privileged components. We expect vulnerabilities to exist, our work and could be used to monitor native binaries dis- of course, but we hope they will be harder to exploit than a tributed with extensions. single cross-site scripting hole. Our work is also related to mashups, which are web pages that result from sophisticated communication and Acknowledgments data sharing between multiple parties (e.g., plotting data from one source on a map from another source). In a We would like to thank Nick Baum, Erik Kay, Collin sense, a browser is a mashup combining extension code Jackson, Matt Perry, Dawn Song, David Wagner, and the and web content into a personalized browsing experience. Google Chrome Team. This work is partially supported Our design draws inspiration from MashupOS [31] and by the Air Force Office of Scientific Research under MURI OMash [14], albeit taking into account subsequent attacks Grant No. 22178970-4170. and design recommendations [10]. In addition, the isolated worlds heap-segregation mechanism is an outgrowth of the References perspective expressed in [12]. Finally, placing the exten- sion’s public-key in the URL was suggested in [20] to rem- [1] Arbitrary code execution using bug 459906. edy a vulnerability in Firefox’s signed JAR mechanism. https://bugzilla.mozilla.org/show_bug. Browser extensions are also analogous to kernel mod- cgi?id=460983. ules in operating systems. Buggy kernel modules have long [2] JSON. http://www.json.org. [3] Mozilla Security Advisory 2009-19. been a major cause of failures and security vulnerabilities http://www.mozilla.org/security/ in operating systems. Nooks [29] and SafeDrive [35] em- announce/2009/mfsa2009-19.html. ploy memory access confinement to limit the privileges of [4] Mozilla Security Advisory 2009-39. kernel modules. Although the two problems are analogous, http://www.mozilla.org/security/ the techniques used are quite different. announce/2009/mfsa2009-39.html.
11 [5] Skype. http://www.skype.com. [26] Mozilla Labs. Jetpack. [6] Zemanta. http://www.zemanta.com. https://wiki.mozilla.org/Labs/Jetpack. [7] M. Abadi, M. Budiu, U. Erlingsson, and J. Ligatti. Control- [27] D. Pupius. Fittr Flickr Extension for Chrome. flow integrity: Principles, implementations, and applica- http://code.google.com/p/fittr/. tions. In ACM Conference on Computer and Communica- [28] A. Raskin. Jetpack FAQ. http://www.azarask.in/ tions Security (CCS), November 2005. blog/post/jetpack-faq/, 2009. [8] L. Adamski. Security Severity Ratings. https://wiki. [29] M. M. Swift, B. N. Bershad, and H. M. Levy. Improving the mozilla.org/Security_Severity_Ratings. Reliability of Commodity Operating Systems. ACM Trans- [9] B. Adida, A. Barth, and C. Jackson. Rootkits for JavaScript actions on Computer Systems, 23(1):77–110, 2005. Environments. In 3rd USENIX Workshop on Offensive Tech- [30] R. Wahbe, S. Lucco, T. E. Anderson, and S. L. Graham. Ef- nologies, 2009. ficient Software-Based Fault Isolation. In ACM Symposium [10] A. Barth, C. Jackson, and W. Li. Attacks on JavaScript on Operating Systems Principles (SOSP), 1994. Mashup Communication. In Proceedings of the Web 2.0 Se- [31] H. J. Wang, X. Fan, J. Howell, and C. Jackson. Protec- curity and Privacy 2009. tion and Communication Abstractions for Web Browsers in [11] A. Barth, C. Jackson, C. Reis, and The Google Chrome MashupOS. In 21st ACM Symposium on Operating Systems Team. The Security Architecture of the Chromium Browser. Principles (SOSP), 2007. Technical report, Google, 2008. [32] H. J. Wang, C. Grier, A. Moshchuk, S. T. King, P. Choud- [12] A. Barth, J. Weinberger, and D. Song. Cross-Origin hury, and H. Venter. The Multi-Principal OS Construction of JavaScript Capability Leaks: Detection, Exploitation, and the Gazell Web Browser. In USENIX Security Symposium, Defense. In USENIX Security Symposium, 2009. 2009. [13] A. Boodman and E. Kay. Google Mail Checker. [33] S. Willison. Understanding the Greasemonkey vulnerabil- http://code.google.com/chrome/ ity. http://simonwillison.net/2005/Jul/20/ extensions/samples.html. vulnerability/. [14] S. Crites, F. Hsu, and H. Chen. Omash: Enabling secure web [34] B. Yee, D. Sehr, G. Dardyk, J. B. Chen, R. Muth, T. Or- mashups via object abstractions. In CCS ’08: Proceedings of mandy, S. Okasaka, N. Narula, and N. Fullagar. Native the 15th ACM conference on Computer and communications client: A sandbox for portable, untrusted x86 native code. security, pages 99–108. ACM, 2008. In IEEE Symposium on Security and Privacy, 2009. [15] J. R. Douceur, J. Elson, J. Howell, and J. R. Lorch. Leverag- [35] F. Zhou, J. Condit, Z. Anderson, I. Bagrak, R. En- ing legacy code to deploy desktop applications on the web. nals, M. Harren, G. Necula, and E. Brewer. SafeDrive: USENIX Operating System Design and Implementation In , Safe and recoverable extensions using language-based tech- 2008. niquesXFI. In Symposium on Operating System Design and [16] U.´ Erlingsson, M. Abadi, M. Vrable, M. Budiu, and G. C. Implementation (OSDI), 2006. Necula. XFI: Software guards for system address spaces. In Symposium on Operating System Design and Implementa- tion (OSDI), 2006. A Extension Survey [17] C. Grier, S. T. King, and D. S. Wallach. How I Learned to Stop Worrying and Love Plugins. In Web 2.0 Security and Our extension survey (Section 3.1) examines extensions Privacy, 2009. [18] C. Grier, S. Tang, and S. T. King. Secure Web Browsing from the Firefox Add-on “recommended” directory. We se- with the OP Web Browser. In IEEE Symposium on Security lected two from each category in the directory. The thir- and Privacy, 2008. teen categories are: Alerts & Updates, Appearance, Book- [19] I. Hickson. DOM Core Performance, Test 1. marks, Download Management, Feeds News & Blogging, http://www.hixie.ch/tests/adhoc/perf/ Language Support, Photos Music & Videos, Privacy & Se- dom/artificial/core/001.html. curity, Search Tools, Social & Communication, Tabs, Tool- [20] C. Jackson and A. Barth. Beware of finer-grained origins. In bars, and Web Development. Web 2.0 Security and Privacy, 2008. The twenty-five extensions in our extension survey are: [21] C. Jackson, A. Bortz, D. Boneh, and J. C. Mitchell. Pro- tecting browser state from web privacy attacks. In Proceed- Adblock Plus 1.0.2, Answers 2.2.48, AutoPager 0.5.0.1, ings of the 15th International World Wide Web Conference Auto Shutdown (InBasic) 3.1.1B, Babel Fish 1.84, Cool- (WWW), May 2006. Previews 2.7.4, Delicious Bookmarks 4.3, docked JS- [22] kkovash. How Many Firefox Users Customize Their Console 0.1.1, DownloadHelper 4.3, Download Statusbar Browser? Blog of Metrics, 2009. 2.1.018, File and Folder Shortcuts 1.3, Firefox Showcase [23] R. S. Liverani and N. Freeman. Abusing Firefox Extensions. 0.3.2009040901, Fission 1.3, Glue 4.2.18, GoogleEnhancer Defcon17, July 2009. 1.70, Image Tweak 0.18.1, Lazarus: Form Recovery 1.0.5, [24] M. T. Louw, J. S. Lim, and V. N. Venkatakrishnan. Enhanc- Mouseless Browsing 0.5.2.1, Multiple Tab Handler 0.9.5, ing web browser security against malware extensions. In Quick Locale Switcher 1.6.9, Shareaholic 1.7, Status-bar Journal in Computer Virology, August 2008. [25] Microsoft Developer Network. Introduction of the Protected Scientific Calculator 4.5, TwitterFox 1.7.7.1, WeatherBug Mode API. http://msdn.microsoft.com/en-us/ 2.0.0.4, and Zemanta 0.5.4. library/ms537319(VS.85).aspx.
12