Documents

04

Description
d
Categories
Published
of 13
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
Share
Transcript
  Protecting Browsers from Extension Vulnerabilities Adam Barth, Adrienne Porter Felt, Prateek SaxenaUniversity of California, Berkeley { abarth, afelt, prateeks } @eecs.berkeley.eduAaron BoodmanGoogle, Inc.aa@google.com Abstract  Browser extensions are remarkably popular, with one inthree Firefox users running at least one extension. Althoughwell-intentioned, extensiondevelopersareoftennotsecurityexperts and write buggy code that can be exploited by ma-licious web site operators. In the Firefox extension system,these exploits are dangerous because extensions run withthe user’s full privileges and can read and write arbitrary files and launch new processes. In this paper, we analyze 25  popular Firefox extensions and find that   88%  of theseextensions need less than the full set of available privileges. Additionally, we find that   76%  of these extensions use un-necessarilypowerfulAPIs, makingitdifficulttoreducetheir  privileges. We propose a new browser extension system that improves security by using least privilege, privilege separa-tion, and strong isolation. Our system limits the misdeedsan attacker can perform through an extension vulnerabil-ity. Our design has been adopted as the Google Chromeextension system. 1 Introduction Web browser extensions are phenomenally popular:roughly one third of Firefox users have at least onebrowser extension [23]. Browser extensions modify thecore browser user experience by changing the browser’suser interface and interacting with web sites. For exam-ple, the Skype browser extension rewrites phone numbersfound in web pages into hyperlinks that launch the epony-mous IP-telephony application [5]. Although there havebeen several recent proposals for new web browser archi-tectures [19, 11, 33], little attention has been paid to thearchitecture of browser extension systems.Many extensions interact extensively with arbitrary webpages, creating a large attack surface that attackers canscour for vulnerabilities. In this paper, we focus on  benign-but-buggy  extensions. Most extensions are not written bysecurity experts, and vulnerabilities in benign extensionsare worrisome because Firefox extensions run with thebrowser’s full privileges. If an attacker can exploit an ex-tension vulnerability, the attacker can usurp the extension’sbroad privileges and install malware on the user’s machine.At this year’s DEFCON, Liverani and Freeman presentedattacks against a number of popular Firefox extensions [24].In one example, if the user dragged an image from a mali-cious web page into the extension, the web site operatorcould install a remote desktop server on the user’s machineand take control of the user’s mouse and keyboard.These attacks raise the question of whether browser ex-tensions require such a high level of privilege. To investi-gate this question, we examine  25  popular Firefox exten-sions to determine how much privilege each one requires.We find that only  3  of the  25  extensions require full sys-tem access. The remainder are over-privileged, needlesslyincreasing the severity of extension vulnerabilities. An ex-tension system that narrows this  privilege gap  would reducethe severity of extension exploits, but the Firefox extensionplatform does not provide sufficiently fine-grained privi-leges. For example, many extensions store settings with aninterface that can read and write arbitrary files.We propose a new extension system, built with securityin mind. In particular, we aim to protect users from benign-but-buggy extensions by designing  least privilege ,  privilegeseparation , and  strong isolation  into our extension system.Instead of running with the user’s full privileges, extensionsin our system are limited to a set of privileges chosen atinstall time. If an extension later becomes compromised,the extension will be unable to increase this set of privi-leges. In particular, our case studies of Firefox extensionssuggest that most extensions do not require the privilege toexecute arbitrary code; consequently, the privilege to exe-cute arbitrary code will often be unavailable to an attackerwho compromises an extension in our system.In addition to limiting the overall privileges of each ex-tension, our system further reduces the attack surface of extensions by forcing developers to divide their extensionsinto three components: content scripts, an extension core,and a native binary (see Figure 1): ã  Each  content script   has direct access to the DOM of a single web page and is thereby exposed to poten-  Figure 1. Extensions are divided into three components, each with progressively more privileges andless exposure to malicious web content. tially malicious input. However, content scripts haveno other privileges except for the ability to send mes-sages to the extension core. ã  The  extension core  contains the bulk of the extensionprivileges, but the extension core can only interactwith web content via XMLHttpRequest and contentscripts. Even the extension core does not have directaccess to the host machine. ã  An extension can optionally include a  native binary that can access the host machine with the user’s fullprivileges. The native binary interacts with the ex-tension core via the standard NPAPI interface used byFlash and other browser plug-ins.To gain the user’s full privileges, an attacker would needto convince the extension to forward malicious input fromthe content script to the extension core and from the exten-sion core to the native binary, where the input would needto exploit a vulnerability. We argue that exploiting such amulti-layer vulnerability is more difficult than exploiting asimple cross-site scripting hole in a Firefox extension.Finally, the different components of an extension are iso-lated from each other by strong protection boundaries: eachcomponent runsin aseparateoperating systemprocess. Thecontent script and the extension core run in sandboxed pro-cesses that cannot use most operating system services. Asa first layer of defense, the content script is isolated fromits associated web page by running in a separate JavaScriptheap. Although both the content script and the web pagehave access to the same underlying DOM, the two never ex-change JavaScript pointers, helping prevent JavaScript ca-pability leaks [12].Our extension system design has been adopted byGoogle Chrome and is available in Google Chrome 4. Al-though it is difficult to predict how developers will use theextension system, we believe that this architecture will pro-vide a solid foundation for building more secure extensions. 2 Attacks on Extensions A browser extension is a third-party software modulethat extends the functionality of a web browser, letting userscustomize their browsing experience. Because extensionsinteract directly with untrusted web content, extensions areat risk of attack from malicious web site operators and ac-tive network attackers. In this section, we present a genericthreat model for extension security that applies to both theFirefox extension system and the new extension system weintroduce in this paper. We then focus our attention on theFirefox extension system, providing background materialand examples of real attacks. 2.1 Threat Model We focus on  benign-but-buggy  extensions: we assumethe extension developer is well-intentioned but not a secu-rity expert. The attacker attempts to corrupt the extensionand usurp its privileges. For example, the attacker mightbe able to install malware on the user’s machine if the ex-tension has arbitrary file access. We assume the attacker isunable to entice the user into downloading or running na-tive executables. We further assume the browser itself isvulnerability-free, letting us focus on the additional attack surface provided by extensions.  We consider two related threat models: a web attackerand an active network attacker. The web attacker controls aweb site, canonically  https://attacker.com/ , thatthe user visits. (Note that we do not assume that the userconfusestheattacker’swebsitewithanotherwebsite.) Typ-ically, theattackerattemptstocorruptanextensionwhentheextension interacts with the attacker’s web site. In additionto the abilities of a web attacker, an active network attackercan intercept, modify, and inject network traffic (e.g., HTTPresponses). The active network attacker threat model is ap-propriate, e.g., for a wireless network in a coffee shop. Plug-ins.  In this paper, we focus on browser extensions,whichdifferfrombrowserplug-ins. Plug-insrenderspecificmedia types (such as PDF and Flash) or expose additionalAPIs to web content (such as the Gears APIs). Plug-ins arerequested explicitly by web sites, usually by loading con-tent with a specific MIME type. By way of contrast, ex-tensions interact with web pages without their explicit con-sent. Although plug-in security is an important area of re-search [19, 18], securing browser extensions requires differ-ent techniques. 2.2 Exploiting Firefox Extensions In Firefox, browser extensions run with the same privi-leges as the browser itself. Firefox extensions have full ac-cess to browser internals and the user’s operating system.Extensions can change the functionality of the browser,modify the behavior of web sites, run arbitrary code, andaccess the file system. Firefox extensions combine two dan-gerous qualities: high privilege and rich interaction with un-trusted web content. Taken together, these qualities risk ex-posing powerful privileges to attackers. We describe fourclasses of attacks against browser extensions and the rele-vant mitigations provided by the Firefox extension system: ã  Cross-Site Scripting.  Extension cross-site script-ing (XSS) vulnerabilities result from interacting di-rectly with untrusted web content. For example, if anextension uses  eval  or  document.write  withoutsanitizing the input, the attacker might be able to in- ject a script into the extension. In one recent exam-ple [24], a popular RSS aggregation extension evalu-ated data from the  <description>  element of anarbitrary web site without proper sanitization. To helpmitigate XSS attacks, Firefox provides a sandbox API, evalInSandbox . When evaluating a script using evalInSandbox , the script runs without the exten-sion’s privileges, thereby preventing the script fromcausing much harm. However, use of this sandboxevaluation is discretionary and does not cover everykind of interaction with untrusted content. ã  Replacing Native APIs.  A malicious web page canconfuse (and ultimately exploit) a browser extensionby replacing native DOM APIs with methods of itsown definition. These fake methods might superfi-cially behave like the native methods [9] and trick an extension into performing some misdeed. Tohelp mitigate this class of attack, Firefox automati-cally wraps references to untrusted objects with an XPCNativeWrapper . An  XPCNativeWrapper is analogous to X-ray goggles: viewing a JavaScriptobject through an  XPCNativeWrapper  shows theunderlying native object, ignoring any modificationsmade by the page’s JavaScript. However, this securitymechanism has had a long history of implementationbugs[4,3,1]. Recentworkhasdemonstratedthatthesebugs are exploitable in some extensions [24]. ã  JavaScript Capability Leaks.  JavaScript capabilityleaks [12] are another avenue for exploiting exten-sions. If an extension leaks one of its own objects toa malicious web page, the attacker can often accessother JavaScript objects, including powerful extensionAPIs. For example, an early version of Greasemonkeyexposed a privileged version of   XMLHttpRequest to every web page [34], letting attackers circumventthe browser’s same-srcin policy by issuing HTTP re-quests with the user’s cookies to arbitrary web sitesand reading back the responses. ã  Mixed Content.  An active network attacker can con-trol content loaded via HTTP. The most severe formof this attack occurs when a browser extension loadsa script over HTTP and runs it. The attacker can re-place this script and hijack the extension’s privilegesto install malware. A similar, but less powerful, attack occurs when an extension injects an HTTP script intoan HTTPS page. For example, we discovered that anextension [6] injects an HTTP script into the HTTPSversion of Gmail. (We reported this vulnerability tothe developers of the extension on August 12, 2009,and the developers released a fixed version thereafter.)Even though we might be able to design defenses for eachof these attack classes, we argue that the underlying issue isthat Firefox extensions interact directly with untrusted con-tent while possessing a high level of privilege. 3 Limiting Firefox Extension Privileges A natural approach to mitigating extension vulnerabil-ities is to reduce the privileges granted to extensions. Toevaluate the feasibility of this approach, we studied  25  pop-ular Firefox extensions to determine how much privilege  ! #$%&' ) *#+, -. /012 ) 345 ) 6470 8 (a) Most powerful behavior. ! #$%&'() +#,- . /012 3 (b) Most powerful interface. Figure 2. The chart on the left shows the severity ratings of the most dangerous behaviors exhibitedby each extension. The chart on the right shows the security ratings of the extension interfaces usedto implement these behaviors. each needs to implement its features. In addition to pre-senting our case studies, we also present an algorithm forfinding methods in the Firefox extension API that lead froma less-privileged interface to a more-privileged interface. 3.1 Case Studies We review  25  extensions manually to determine theirprivilege requirements:1. We analyze the behavior of an extension to determinehow much privilege an extension  needs  to realize itsfunctionality, letting us compare its required privilegesto its actual privileges.2. We analyze the implementation of an extension to de-termine how much power the extension  receives , giventhe set of interfaces it uses to realize its functionality.This lets us evaluate how much we could reduce itsprivileges if we limited access to interfaces.We find that most extensions do not require arbitrary filesystem access (the most powerful privilege), meaning thatmost extensions are over-privileged. We also find that ex-tensions commonly use powerful interfaces to accomplishsimple tasks because the Firefox APIs are coarse-grained. Methodology.  We randomly selected two extensionsfrom each of the  13  categories in the “recommended” sec-tion of the Firefox Add-on directory. (See Appendix A fora list.) We excluded one of the selected extensions becauseit was distributed only as a binary. We verified that the  25 subject extensions were also highly ranked in the “popu-lar” directory. To determine the extensions’ functionality,we ran each extension and manually exercised its user in-terface. We also located usage of the extension system APIby searching for explicit interface names in the extensions’sourcecode. (Thismethodologyunder-approximatesthesetof interfaces.) We then manually correlated the interfaceswith the extensions’ functionality. This process could notbe automated because understanding high-level functional-ity requires human judgement.To compare the set of interfaces with extension function-ality, weassignedoneoffiveratings(critical, high, medium,low, and none) to each interface and functionality based onthe Firefox Security Severity Ratings [8]: ã  Critical:  Can run arbitrary code on the user’s system(e.g., arbitrary file access) ã  High:  Can access site-specific confidential informa-tion (e.g., cookies and password) or the Document Ob- ject Model (DOM) of all web pages ã  Medium:  Can access private user data (e.g., recent his-tory) or the DOM of specific web pages ã  Low:  Can annoy the user ã  None:  No security privileges (e.g., a string) or privi-leges limited to the extension itself  Results.  Of the  25  subject extensions, only  3  require criti-cal privileges (see Figure 2(a)). Therefore,  22  of the subjectextensions are over-privileged because all extensions havethe privilege to perform critical tasks. Despite the fact thatonly  3  need critical privileges,  19  use a critical-rated in-terface (see Figure 2(b)). An additional  3  use high-ratedinterfaces despite needing only medium or less privileges,meaningthatatotalof  19 extensionsuseinterfacesthathavebroader privileges than they require. Figure 3 shows the de-tailed results. We summarize these results below: ã  Three extensions, all download managers, require theability to create new processes. (These are the only
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks