An Evaluation of the Google Chrome Extension Security Architecture

An Evaluation of the Google Chrome Extension Security Architecture Nicholas Carlini, Adrienne Porter Felt, and David Wagner University of California, Berkeley [email protected], [email protected], [email protected] Abstract developers need to build extensions that are robust to attacks originating from malicious websites and the net- Vulnerabilities in browser extensions put users at risk by work. Extensions can read and manipulate content from providing a way for website and network attackers to websites, make unfettered network requests, and access gain access to users’ private data and credentials. Exten- browser userdata like bookmarks and geolocation. In the sions can also introduce vulnerabilities into the websites hands of a web or network attacker, these privileges can that they modify. In 2009, Google Chrome introduced be abused to collect users’ private information and au- a new extension platform with several features intended thentication credentials. to prevent and mitigate extension vulnerabilities: strong Google Chrome employs three mechanisms to prevent isolation between websites and extensions, privilege sep- and mitigate extension vulnerabilities: aration within an extension, and an extension permission system. We performed a security review of 100 Chrome extensions and found 70 vulnerabilities across 40 exten- • Privilege separation. Chrome extensions adhere to sions. Given these vulnerabilities, we evaluate how well a privilege-separated architecture [23]. Extensions each of the security mechanisms defends against exten- are built from two types of components, which are sion vulnerabilities. We find that the mechanisms mostly isolated from each other: content scripts and core succeed at preventing direct web attacks on extensions, extensions. Content scripts interact with websites but new security mechanisms are needed to protect users and execute with no privileges. Core extensions do from network attacks on extensions, website metadata at- not directly interact with websites and execute with tacks on extensions, and vulnerabilities that extensions the extension’s full privileges. add to websites. We propose and evaluate additional de- • Isolated worlds. Content scripts can read and mod- fenses, and we conclude that banning HTTP scripts and ify website content, but content scripts and websites inline scripts would prevent 47 of the 50 most severe vul- have separate program heaps so that websites can- nerabilities with only modest impact on developers. not access content scripts’ functions or variables. • Permissions. Each extension comes packaged with a list of permissions, which govern access to the 1 Introduction browser APIs and web domains. If an extension has a core extension vulnerability, the attacker will only Browser extensions can introduce serious security vul- gain access to the permissions that the vulnerable nerabilities into users’ browsers or the websites that ex- extension already has. tensions interact with [20, 32]. In 2009, Google Chrome introduced a new extension platform with several secu- In this work, we provide an empirical analysis of rity mechanisms intended to prevent and mitigate ex- these security mechanisms, which together comprise a tension vulnerabilities. Safari and Mozilla Firefox have state-of-the-art least privilege system. We analyze 100 since adopted some of these mechanisms for their own Chrome extensions, including the 50 most popular ex- extension platforms. In this paper, we evaluate the se- tensions, to determine whether Chrome’s security mech- curity of the widely-deployed Google Chrome extension anisms successfully prevent or mitigate extension vulner- platform with the goal of understanding the practical suc- abilities. We find that 40 extensions contain at least one cesses and failures of its security mechanisms. type of vulnerability. Twenty-seven extensions contain Most extensions are written by well-meaning devel- core extension vulnerabilities, which give an attacker full opers who are not security experts. These non-expert control over the extension. Based on this set of vulnerabilities, we evaluate the 2 Extension Security Background effectiveness of each of the three security mechanisms. Our primary findings are: 2.1 Threat Model • The isolated worlds mechanism is highly successful In this paper, we focus on non-malicious extensions that at preventing content script vulnerabilities. are vulnerable to external attacks. Most extensions are • The success of the isolated worlds mechanism ren- written by well-meaning developers who are not secu- ders privilege separation unnecessary. However, rity experts. We do not consider malicious extensions; privilege separation would protect 62% of exten- preventing malicious extensions requires completely dif- sions if isolated worlds were to fail. In the remain- ferent tactics, such as warnings, user education, security ing 38% of extensions, developers either intention- scans of the market, and feedback and rating systems. ally or accidentally negate the benefits of privilege Benign-but-buggy extensions face two types of attacks: separation. This highlights that forcing developers to divide their software into components does not automatically achieve security on its own. • Network attackers. People who use insecure net- • Permissions significantly reduce the severity of half works (e.g., public WiFi hotspots) may encounter of the core extension vulnerabilities, which demon- network attackers [26, 21]. A network attacker’s strates that permissions are effective at mitigating goal is to obtain personal information or credentials vulnerabilities in practice. Additionally, dangerous from a target user. To achieve this goal, a network permissions do not correlate with vulnerabilities: attacker will read and alter HTTP traffic to mount developers who write vulnerable extensions use per- man-in-the-middle attacks. (Assuming that TLS missions the same way as other developers. works as intended, a network attacker cannot compromise HTTPS traffic.) Consequently, data and Although these mechanisms reduce the rate and scope scripts loaded over HTTP may be compromised. of several classes of attacks, a large number of high- privilege vulnerabilities remain. If an extension adds an HTTP script – a JavaScript We propose and evaluate four additional defenses. Our file loaded over HTTP – to itself, a network attacker extension review demonstrates that many developers do can run arbitrary JavaScript within the extension’s not follow security best practices if they are optional, so context. If an extension adds an HTTP script to we propose four mandatory bans on unsafe coding prac- an HTTPS website, then the website will no longer tices. We quantify the security benefits and functional- benefit from the confidentiality, integrity, and au- ity costs of these restrictions on extension behavior. Our thentication guarantees of HTTPS. Similarly, insert- evaluation shows that banning inline scripts and HTTP ing HTTP data into an HTTPS website or extension scripts would prevent 67% of the overall vulnerabilities can lead to vulnerabilities if the untrusted data is al- and 94% of the most dangerous vulnerabilities at a rela- lowed to execute as code. tively low cost for most extensions. In concurrent work, Google Chrome implemented Content Security Policy • Web attackers. Users may visit websites that host (CSP) for extensions to optionally restrict their own be- malicious content (e.g., advertisements or user com- havior. Motivated in part by our study [5], future versions ments). A website can launch a cross-site script- of Chrome will use CSP to enforce some of the manda- ing attack on an extension if the extension treats the tory bans that we proposed and evaluated. website’s data or functions as trusted. The goal of a web attacker is to gain access to browser userdata Contributions. We contribute the following: (e.g., history) or violate website isolation (e.g., read • We establish the rate at which extensions contain another site’s password). different types of vulnerabilities, which should direct future extension security research efforts. Extensions are primarily written in JavaScript and • We perform the first large-scale study of the ef- HTML, and JavaScript provides several methods for con- fectiveness of privilege separation when developers verting strings to code, such as eval and setTimeout. who are not security experts are required to use it. If used improperly, these methods can introduce code • Although it has been assumed that permissions mit- injection vulnerabilities that compromise the extension. igate vulnerabilities [12, 14, 10], we are the first to Data can also execute if it is written to a page as evaluate the extent to which this is true in practice. HTML instead of as text, e.g., through the use of • We propose and evaluate new defenses. This study document.write or document.body.innerHTML. Ex- partially motivated Chrome’s adoption of a new tension developers need to be careful to avoid passing mandatory security mechanism. unsanitized, untrusted data to these execution sinks. Network attacker Network attacker (if website is HTTP) (if connection is HTTP) Extension Website Content Script Core Extension Servers [attacker] Browser API Figure 1: The architecture of a Google Chrome extension. 2.2 Chrome Extension Security Model • Isolated worlds. The isolated worlds mechanism is intended to protect content scripts from web attack- Many Firefox extensions have publicly suffered from ers. A content script

Load more