tool, which in turn led us to sacrifice soundness.
Vex is implemented in Java (∼7000 LOC), and utilizes a
sources obtained from the pre-processing of the extension’s
event is triggered and the event-handler is called. We extract
all such calls to the event-handlers from the XUL files and
run them using Vex’s abstract operational semantics.
During the execution of the program using the abstract
operational semantics outlined in Section 4, if the program
reaches a vulnerable sink, it checks if the inputs or assignments to the sink are tainted. If they are tainted, Vex reports
the occurrence of the flow along with the source objects and
sink locations in the code. The source objects are the objects
described in Section 3 and the sink locations are the points
where the sinks described in Section 3 are encountered during
the execution. The rest of this section summarizes our results.
The number of loop unrollings can be set as a parameter
in the Vex analysis engine (in our experiments, a bound of
just one was used). The Vex implementation has a number
of optimizations to improve memory usage and speed. To
save memory, abstract heaps are freed when backtracking
in the depth-first search. But to save time, abstract heaps at
join points are cached and compared when other paths hit
these points, to avoid exploring paths unnecessarily.
5. 1. evaluation methodology
The extensions we analyzed were chosen as follows. First,
in October 2008, we built a suite of extensions using a random sample of 1827 extensions from the Mozilla add-ons
Web site, by downloading the first extensions in alphabetical
order for all subject categories. This extension suite had two
extensions with known vulnerabilities. In November 2009,
we downloaded 699 of the most popular extensions and 8
figure 5. flows from injectible sources to executable sinks.
extensions with known vulnerabilities. The random sample
and the popular extensions had 74 extensions in common,
for a total of 2460 extensions. Our suite includes multiple
versions of some extensions, allowing cross-version comparisons. For instance, we found a new version of the Fizzle (see
Bandhakavi et al.
2), to be vulnerable even though its authors
tried to fix the vulnerabilities in the previous version.
and ran Vex on them, using a 2. 4 GHz 64 bit × 86 processor
with a maximum heap size of 16GB for the JVM.
To evaluate the effectiveness of Vex, we perform two
kinds of experiments. First, we run Vex on the downloaded
extensions and check if any of them have one of the malicious flow patterns. Second, we check if Vex can detect
known extension vulnerabilities.
5. 2. experimental results
finding flows from injectible sources to executable sinks:
Figure 5 summarizes the experimental results for flows
that are from injectible sources to executable sinks (flows
for which the sinks are eval and innerHTML). Of the 2460
extensions analyzed by Vex, a grep showed that a total
of 977 extensions had the occurrence of either the string
“eval” or the string “innerHTML” or both.
The first column of Figure 5 indicates the exact source
to sink flow pattern checked by Vex. The second column
indicates the number of extensions on which Vex reports
an alert with corresponding flows. On an average, Vex took
11.5s per extension. It took about a week to analyze all the
extensions with flows from untrusted sources to eval and
To look for potential attacks, we manually analyzed the
extensions with suspect flows found by Vex, spending about
20 min per extension on average. The next column reports
the number of extensions on which we could engineer an
attack based on the flows reported by Vex. We were able to
attack nine extensions, of which only two extensions (Fizzle
version 0.5 and Beatnik v- 1.0) were already known to be
vulnerable. The rest of the attacks are new.
The next column shows the extensions where the source
is provided either by the extension user or the extension
developer or computed from the system parameters by the
Source from user/
Content Doc to eval
Prefs to eval
Unknown var to eval
Content Doc to innerHTML
RDF to innerHTML
Prefs to innerHTML
popupNode to innerHTML
Unknown to innerHTML
Attackable Extensions are listed in Section 5. 2
Source is a
trusted Web site