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
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
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
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
scripts that can lead to attacks if run with chrome privileges.
content.document) accesses the browser’s content page
directly, and hence is an untrusted source. Also, the browser
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.