obfuscate extension functionality, but we assume the developer could write incorrect code that contains vulnerabilities.

We use two attack models. First, we consider attacks that originate from Web sites, and we assume the attacker can send arbitrary HTML and JavaScript to the user’s browser, modeling the usage model that assumes the user can navigate to any page on the internet. We focus on attacks where this untrusted data can lead to code injection or privilege escalation through buggy extensions. In the second attack model, we assume the same model as above, but we consider certain Web sites as trusted. For example, if an extension gleans information from the Facebook Web site, we assume that the Facebook data will not include arbitrary HTML and JavaScript, but only well formatted and trusted data.

According to the Mozilla developer site, Mozilla has a team of volunteers who help vet extensions manually. They run new and updated extensions isolated in a virtual machine to test the user experience. The editors also use a validation tool, which uses grep to look for key indicators of bugs. Many of the patterns they search for involve interactions between extensions and Web pages, and they use their understanding of these patterns to help guide their inspection of the code. Our goal is to help automate this process, so that analysts can quickly hone in on particular snippets of code that are likely to contain security vulnerabilities. Figure 1 shows our overall work flow for using Vex: when extensions are subject to analysis by Vex, it reports precise code paths from untrusted sources to executable sinks in the extensions’ code, which an expert must manually examine to check whether they can be used to mount an attack.

3. Vex infoRmation fLo W PatteRns
Firefox has two privilege levels: page for the Web page
displayed in the browser’s content pane, and chrome for
elements belonging to Firefox and its extensions. Page privi-
leges are more restrictive than chrome privileges. For exam-
ple, a page loaded from illinois.edu can only access
content from illinois.edu. Firefox code and extensions
run with full chrome privileges, which enable them to access
all browser states and events, OS resources like the file sys-
tem and network, and all Web pages. Extensions also can
include their own user-interface components via a chrome
document, which can run with full chrome privileges.

3. 1. Untrusted sources

We now describe the untrusted JavaScript objects that extensions can access. Untrusted objects might contain foreign scripts that can lead to attacks if run with chrome privileges.

The JavaScript content-document object (window. content.document) accesses the browser’s content page directly, and hence is an untrusted source. Also, the browser sets JavaScript pop-up nodes (document.popupNode) when the user right-clicks on document object model (DOM) elements. If this DOM element is part of the page content, then it includes untrusted page content.

One API that extensions use to access persistent state is the Resource Description Framework (RDF). RDF is a model for describing hierarchical relationships between browser resources17 and is used by the browser to store persistent data, like bookmarks. Extension developers can store persistent extension data in an RDF file, or access browser resources stored in RDF format. However, RDF data can

figure 1. the overall analysis process of Vex.