Securing Script-Based Extensibility in Web Browsers Vladan Djeric, Ashvin Goel University of Toronto Abstract cess the local disk to store its URL blacklist and access web pages to filter their content. This com- Web browsers are increasingly designed to be ex- bination is needed for writing powerful extensions, tensible to keep up with the Web’s rapid pace of but it creates challenges for securely executing web change. This extensibility is typically implemented page scripts. Specifically, when extensions interact using script-based extensions. Script extensions with web pages, there is a risk of a privilege escala- have access to sensitive browser APIs and content tion attack that grants web page scripts the full privi- from untrusted web pages. Unfortunately, this pow- leges of script extensions and control over the entire erful combination creates the threat of privilege es- browser process. Privilege escalation vulnerabilities calation attacks that grant web page scripts the full are perhaps even more critical than memory safety privileges of extensions and control over the entire vulnerabilities because script-based attacks can of- browser process. ten be executed reliably. This paper makes two contributions. First, it Our goals in this paper are two-fold: 1) under- describes the pitfalls of script-based extensibility standing the nature of script-based privilege escala- based on our study of the Firefox web browser. We tion vulnerabilities, 2) proposing methods to secure find that script-based extensions can lead to arbi- the Firefox browser against them. Privilege esca- trary code injection and execution control, the same lation vulnerabilities are common in Firefox, and types of vulnerabilities found in unsafe code. Sec- comprise roughly a third of the critical vulnerabil- ond, we propose a taint-based system to track the ity advisories. They arise from unsafe extension be- spread of untrusted data in the browser and to de- haviors or bugs in the Firefox security mechanisms tect the characteristic signatures of privilege escala- that regulate interactions between trusted native or tion attacks. We evaluate this approach by using ex- extension scripts and untrusted web page scripts. ploits from the Firefox bug database and show that These vulnerabilities have appeared regularly in ev- our system detects the vast majority of attacks with ery version of the browser and exist even in the lat- almost no false alarms. est versions. This is despite continuing effort from a 1 Introduction dedicated team of security developers that have pro- Most web browsers today provide powerful exten- gressively improved the browser security model. sibility features, including native and script-based The Firefox security model consists of a com- extensions. Native extensions (or plugins) are typi- bination of stack inspection and one-way names- cally used when performance is critical (e.g., virtual pace isolation. The stack inspection mechanism, machines for Java, Flash, media players, etc.), while implemented at the boundary of the script and na- script extensions ensure memory safety and have the tive code, regulates accesses to sensitive native in- advantage of being inherently cross-platform and terfaces based on the principals of the caller. For amenable to rapid development. Examples of pop- example, a local file access is denied if the current ular script extensions include the Firefox Adblock stack contains a frame associated with an untrusted 1 extension [1] that filters content from blacklisted ad- principal. Namespace isolation is used to enforce vertising URLs, and Greasemonkey [4] that allows the same-origin policy for web page scripts. This users to install arbitrary scripts in web pages for cus- policy limits interactions between scripts and doc- tomization or to create client-side mashup pages. uments loaded from different origins. The names- one way Script extensions must have access to both sensi- pace isolation is in that script extensions tive browser APIs and content from untrusted web 1A principal represents the code’s origin and, for web page pages. For example, Adblock must be able to ac- scripts, it consists of a scheme, host, port combination. are privileged and allowed to access content names- ilege escalation vulnerabilities and easily-available paces, but web page scripts should not be able to exploits. Our results show that we can detect the obtain a reference to the privileged namespace. This vast majority of attacks with almost no false alarms policy is designed to enforce the same-origin policy and modest overhead. and defend against privilege escalation attacks. Below, Section 2 provides background on the These security mechanisms are well understood, Firefox security model. Section 3 presents our but they have two flaws: 1) relying entirely on prin- classification of privilege escalation vulnerabilities cipals as a measure of trustworthiness for stack in- and sample exploits. Section 4 describes our taint- spection, and 2) depending on one-way namespace based approach for securing script-based extensi- isolation to work correctly. In practice, an exploit bility. Section 5 provides an evaluation of our ap- can leverage browser bugs or vulnerable extensions proach. Section 6 describes related work in the to confuse the browser into assigning wrong princi- area and Section 7 presents our conclusions and de- pals to code or executing data or code with wrong scribes future work. principals, thus defeating stack inspection. Second, 2 The Firefox Browser reference leaks can occur because of interactions between privileged and unprivileged scripts, com- In this section, we provide an overview of the Fire- promising namespace isolation and allowing un- fox architecture and its security model. privileged scripts to affect the execution of privi- 2.1 Architecture leged scripts. As a result, we find that arbitrary code injection and execution control vulnerabilities that Figure 1 shows a simplified version of the Fire- commonly exist in unsafe code can also occur with fox architecture relevant to this work. The basic script-based extensibility. browser functionality is provided by native C++ Based on the flaws described above, our solution components written using Mozilla’s cross-platform for securing the Firefox browser consists of com- component model (XPCOM). XPCOM components bining tainting with the existing stack-based secu- implement functionality such as file and socket ac- rity model. Our approach guarantees that tainted cess, the document object model (DOM) for rep- data will not be executed as privileged code. Taint- resenting HTML documents, and higher-level ab- ing all data from untrusted origins and propagating stractions, such as bookmarks, and expose this func- the tainted data throughout the browser provides a tionality via the XPIDL interface layer. The Script much stronger basis for making security decisions. Security Manager (SSM) is an XPCOM component In essence, our attack detectors “second guess” the responsible for implementing the browser’s security security decisions of the browser by taking into ac- mechanisms. count one additional piece of information, i.e. the The JavaScript interpreter accesses XPCOM taint status. This solution is conceptually simple functionality via the XPConnect translation layer. and well-suited for the browser’s security model be- This layer allows the interpreter and the XPCOM cause namespace isolation already provides a se- classes to work with each others data types transpar- curity barrier between the taint sources in content ently. XPConnect also serves as the primary secu- namespaces and privileged code residing in exten- rity barrier for enforcing the browser’s same origin sion namespaces. As a result, we show that it is un- policy and restricting access to sensitive XPCOM likely that attacks will be detected erroneously, even interfaces. if we fully taint all data and scripts from web pages. Firefox’s script extensions and privileged UI The contributions of this paper are two-fold: 1) scripts, shown in Figure 1, are loaded from lo- we analyze and classify script-based privilege esca- cal files through URIs with the “chrome” protocol. lation vulnerabilities in the commonly used Firefox They are privileged and have access to a greater browser, 2) we use taint-based stack inspection to number of XPCOM interface methods than web design effective signatures for script-based exploits page scripts and are not subject to the browser’s and evaluate this approach. We use Firefox version same origin policy. Similar to other browsers, Fire- 1.0 for the evaluation because it has several priv- fox also supports native plugins for Java, Flash, etc. Browser of operations (e.g., call a function F, get a property Web page Extension UI A, set a property B), and the object is the principal JS JS JS of the object that is the target of the operation. This JS Interpreter security mechanism is implemented in the Script XPConnect XPIDL Interfaces Security Manager, and invoked by XPConnect to DODOMM objectsobjects SSMSSM regulate access to sensitive XPCOM interfaces and XPCOM classes by the interpreter to limit access to sensitive func- BookmarksBookmarks objobjectsects tions and object properties. The principal of a web page script is defined by Figure 1: The Firefox architecture. the origin of the document containing the script (its protocol, hostname, and port). The Script Security Although potential security vulnerabilities can ex- Manager determines the subject principal by walk- ist within plugin implementations, we do not ad- ing down the JavaScript stack until it finds a stack dress them. However, with appropriate sandboxing frame with a script principal. The object principal is of plugins [14, 23], we would be able to monitor any determined by walking up the object’s parent chain script interactions with the plugins. (scope chain) in its namespace until an ancestor ob- ject with a principal is found. For web pages, the ob- 2.2 Security Model ject’s parent chain leads to a top-level HTML docu- Firefox primarily uses two security schemes, ment associated with the window object.