Please do not remove this page Analyzing Information Flow in Javascript-based Browser Extensions Dhawan, Mohan; Ganapathy, Vinod https://scholarship.libraries.rutgers.edu/discovery/delivery/01RUT_INST:ResearchRepository/12643416230004646?l#13643522920004646 Dhawan, M., & Ganapathy, V. (2009). Analyzing Information Flow in Javascript-based Browser Extensions. Rutgers University. https://doi.org/10.7282/T3TT4VCM This work is protected by copyright. You are free to use this resource, with proper attribution, for research and educational purposes. Other uses, such as reproduction or publication, may require the permission of the copyright holder. Downloaded On 2021/09/25 16:45:03 -0400 Rutgers University DCS Technical Report 648, April 2009 Analyzing Information Flow in JavaScript-based Browser Extensions Mohan Dhawan and Vinod Ganapathy Department of Computer Science Rutgers, The State University of New Jersey Abstract Flash players, ActiveX), browser helper objects (BHOs, e.g., toolbars) and add-ons. JavaScript-based browser extensions (JSEs) enhance This paper concerns JavaScript-based browser ex- the core functionality of web browsers by improving tensions (JSEs). Such extensions are written primarily their look and feel, and are widely available for com- in JavaScript, and are widely available and immensely modity browsers. To enable a rich set of functionalities, popular (as “add-ons”) for Firefox [4] and related tools, browsers typically execute JSEs with elevated privileges. such as Thunderbird. Notable examples of JSEs for For example, unlike JavaScript code in a web applica- Firefox include Greasemonkey [5], which allows user- tion, code in a JSE is not constrained by the same-origin defined scripts to customize how web pages are ren- policy. Malicious JSEs can misuse these privileges to dered, Firebug [3], a JavaScript development environ- compromise confidentiality and integrity, e.g., by steal- ment, and NoScript [9], a JSE that aims to improve se- ing sensitive information, such as cookies and saved curity by blocking script execution from certain web- passwords, or executing arbitrary code on the host sys- sites. Other browsers like Internet Explorer and Google tem. Even if a JSE is not overtly malicious, vulnera- Chrome also support extensions (e.g., scriptable plug- bilities in the JSE and the browser may allow a remote ins and ActiveX controls) that contain or interact with attacker to compromise browser security. JavaScript code. We present Sabre (Security Architecture for Browser However, recent attacks show that JSEs pose a threat Extensions), a system that uses in-browser information- to browser security. Two factors contribute to this threat: flow tracking to analyze JSEs. Sabre associates a label (1) Inadequate sandboxing of JavaScript in a JSE. with each in-memory JavaScript object in the browser, Unlike JavaScript code in a web application, which exe- which determines whether the object contains sensitive cutes with restricted privileges [10], JavaScript code in a information. Sabre propagates labels as objects are JSE executes with the privileges of the browser. JSEs are modified by the JSE and passed between browser sub- not constrained by the same-origin policy [37], and can systems. Sabre raises an alert if an object contain- freely access sensitive entities, such as the cookie store ing sensitive information is accessed in an unsafe way, and browsing history. Thus, for instance, JavaScript e.g., if a JSE attempts to send the object over the net- in a JSE is allowed to send an XMLHttpRequest to any work or write it to a file. We implemented Sabre by mod- web domain. Even though JavaScript only provides re- ifying the Firefox browser and evaluated it using both stricted language-level constructs for I/O, browsers typ- malicious JSEs as well as benign ones that contained ically provide cross-domain interfaces that enable a JSE exploitable vulnerabilities. Our experiments show that to perform I/O. For example, although JavaScript does Sabre can precisely identify potential information flow not have language-level primitives to interact with the violations by JSEs. file system, JSEs in Firefox can access the file system via constructs provided by the XPCOM (cross-domain com- ponent object model) interface [8]. Importantly, these 1. Introduction features are necessary to create expressive JSEs that Modern web browsers support an architecture that support a rich set of functionalities. For example, JSEs lets third-party extensions enhance the core functional- that provide cookie and password management function- ity of the browser. Such extensions enhance the look and ality rely critically on the ability to access the cookie and feel of the browser and help render rich web content, password stores. such as multimedia. Extensions are widely available However, JSEs from untrusted third parties may con- for commodity browsers as plugins (e.g., PDF readers, tain malicious functionality that exploits the privileges 1 Rutgers University DCS Technical Report 648, April 2009 that the browser affords to JavaScript code in an exten- the network or write it to a file. In addition to detecting sion. Examples of such JSEs exist in the wild. They are such confidentiality violations, Sabre also uses the same extremely easy to create and can avoid detection using mechanism to detect integrity violations, e.g., if a JSE stealth techniques [12, 14, 15, 16, 18, 40]. Indeed, we attempts to execute a script received from an untrusted wrote several such JSEs during the course of this project. domain with elevated privileges. (2) Browser and JSE vulnerabilities. Even if a JSE Sabre differs from prior work [21] that uses is not malicious, vulnerabilities in the browser and in information-flow tracking to analyze plugins and BHOs JSEs may allow a malicious website to access and mis- because it tracks information flow at the level of use the privileges of a JSE [13, 34, 38, 39, 44]. Vulner- JavaScript instructions and does so within the browser. abilities in older versions of Firefox and Greasemonkey In contrast, prior work on plugin security tracks infor- allowed a remote attacker to access the file system on mation flow at the system level by tracking information the host machine [34, 44]. Similarly, vulnerabilities in flow at the granularity of machine instructions. These Firebug [13, 38] allowed a remote attacker to execute ar- differences allow Sabre to report better forensic infor- bitrary commands on the host machine using an exploit mation with JSEs because an analyst can explain flow akin to cross-site scripting. These attacks, which are de- of information at the granularity of JavaScript objects scribed in detail in Section 2, exploit subtle interactions and instructions rather than at the granularity of mem- between the browser and JSEs. ory words and machine instructions. For example, prior While there is much prior work on the security of un- work [21] required the system-level information-flow trusted browser extensions such as plugins and BHOs tracker to have access to OS-aware views in order to at- (which are distributed as binary executables) particu- tribute suspicious actions to specific plugins and BHOs. larly in the context of spyware [21, 29, 30], there is In contrast, Sabre can readily attribute suspicious actions relatively little work on analyzing the security of JSEs. to the JSEs that performed these actions. Finally, Sabre Existing techniques to protect against an untrusted JSE can be implemented by modifying the web browser and rely on load-time verification of the integrity of the JSE, does not require the browser to execute in specialized e.g., by ensuring that scripts are digitally signed by a information-flow tracking environments (e.g., a modi- trustworthy source. However, such verification is ag- fied system emulator). nostic to the code in a JSE and cannot prevent attacks Prior work [17, 41] has also explored JavaScript- enabled by vulnerabilities in the browser or the JSE. Ter- level information-flow tracking as a client-side defense Louw et al. [40] developed a runtime agent to detect ma- against web-application vulnerabilities, such as cross- licious JSEs by monitoring XPCOM calls and ensuring site scripting. Although Sabre employs similar tech- that these calls conform to a user-defined security pol- niques to propagate labels, it differs from prior work icy. Such a security policy may, for instance, prevent in two ways. First, Sabre precisely tracks cross-domain a JSE from accessing the network after it has accessed flows, i.e., information flows in which a JavaScript ob- browsing history. Unfortunately, XPCOM-level moni- ject is passed between different browser subsystems, of- toring of JSEs is too coarse-grained and can be overly ten being converted into different representations as it restrictive. For example, one of their policies disallows is passed. Handling such flows is important because XPCOM calls when SSL is in use, which may prevent JSEs extensively use cross-domain calls to access web some JSEs from functioning in a https browsing ses- documents (the DOM), local storage and the network. sion. XPCOM-level monitoring can also miss attacks, For example, Sabre precisely tracks DOM nodes that e.g., a JSE may disguise its malicious actions so that are accessed by a JSE and propagates labels between they appear benign to the monitor (in a manner akin to the DOM and the JavaScript interpreter. Sabre also mimicry attacks [42]). modifies the XPCOM interface to propagate labels pre- This paper presents Sabre, a system that uses in- cisely across other browser subsystems. In contrast, browser information-flow tracking to analyze JSEs. prior work only tracked information flows within the Sabre associates each in-memory JavaScript object with JavaScript interpreter and provided rudimentary support a label that determines whether the object contains sensi- for label propagation across the DOM [41]. Second, tive information. Sabre modifies this label when the cor- Sabre incorporates support to declassify or endorse in- responding object is modified by JavaScript code (con- formation flows.