After You, Please: Browser Extensions Order Attacks and Countermeasures
Pablo Picazo-Sanchez Juan Tapiador Chalmers | University of Gothenburg, Carlos III University Gothenburg, Sweden Madrid, Spain Gerardo Schneider Chalmers | University of Gothenburg, Gothenburg, Sweden
Abstract ular browsers as of this writing (April 2018) are Chrome (77.9%), Firefox (11.8%), Internet Explor- Browser extensions are small applications executed er/Edge (4.1%), Safari (3.3%) and Opera (1.5%) in the browser context that provide additional capa- [18]. Most browsers allow users to install small bilities and enrich the user experience while surfing applications, generally developed by third parties, the web. The acceptance of extensions in current that provide additional functionality or enhance the browsers is unquestionable. For instance, Chrome’s user experience while browsing. Such plug-ins are official extension repository has more than 63,000 known as browser extensions and they interact with extensions, with some of them having more than the browser by sharing common resources such as 10M users. When installed, extensions are pushed tabs, cookies, HTML content or storage capabilities. into an internal queue within the browser. The or- der in which each extension executes depends on a In this paper we focus on Chromium [12], which number of factors, including their relative installa- is an open source browser and the basis for Chrome, tion times. In this paper, we demonstrate how this Opera, Comodo, Dragon and the Yandex browser. order can be exploited by an unprivileged malicious Extensions installed in Chromium can also run in all extension (i.e., one with no more permissions than mentioned browsers. The execution engine is ex- those already assigned when accessing web content) actly the same in all the browsers and follows the to get access to any private information that other same pipeline model that will be explained in some extensions have previously introduced. Our solution detail later (Section3). For this reason, we will re- does not require modifying the core browser engine fer to Chrome and Chromium interchangeably. Ex- as it is implemented as another browser extension. tensions in Chromium can be of three types: con- We prove that our approach effectively protects the tent scripts, background pages, or both. In what fol- user against usual attackers (i.e., any other installed lows, our main focus is on content scripts, which are extension) as well as against strong attackers having JavaScript files that run in the context of the loaded access to the effects of all installed extensions (i.e., web page. It is important to emphasize that the main knowing who did what). We also prove soundness aim of content scripts is to access and interact with arXiv:1908.02205v1 [cs.CR] 6 Aug 2019 and robustness of our approach under reasonable as- the Document Object Model (DOM). This fact alone sumptions. raises a fundamental privacy question, since it is ex- plicitly assumed that extensions will have full access to any (sensitive or not) content that the user is ac- 1 Introduction cessing. Browsers (including Chromium) dodge this issue by assuming that the user should trust the ex- Web browsers have become essential tools that are tension before installing it. In this paper we do not installed on nearly all computers. The most pop- address this problem, which is essentially related to
1 determining if an extension’s behavior is benign or
E1 E2 E3
E2
2 In JavaScript, extensions subscribe to events by manages tasks and microtasks. A task—a click using the addEvenListener() function. In our event, for instance—is run in its own thread and is example above we use capturing, so the first alert() composed of a set of JavaScript sentences, actions to will correspond to the
3 Main Thread Worker Thread servation is the basis for the attack discussed in this Main World Isolated World (Content Scripts) Worker World paper.
CSN CS1
V8 DOM DOM DOM DOM 3 Attacker Model Wrapper Wrapper Wrapper Wrapper Chromium manages all installed extensions through the class ExtensionRegistry which is implemented in extension_registry.cc and the associated header file extension_registry.h. This class implements meth- Blink DOM Object ods to add, remove or retrieve all extensions that DOM Object for a particular browser context have been enabled, disabled, blocked, blacklisted, etc. Each set of ex- tensions is internally managed through the Exten- Figure 2: Browser Extensions Architecture in sionSet class implemented in extension_set.h and ex- Chromium tension_set.cc. This is just a standard C++ map to manage sets with methods to insert, remove and re- trieve items. Importantly, it also provides a standard this world concept means that the content scripts of C++ iterator to enumerate all set elements. Overall, each extension will run its own JavaScripts over dif- this means that installed extensions in Chromium are ferent DOMs. However, all these DOMs are syn- placed in a pipeline and are called sequentially to chronized so that all changes made by each indi- inject the content script(s) in the DOM. Apart from vidual JavaScript will automatically be sent to other that, the position at which the browser injects con- DOMs (other wrappers and the main DOM the user tent scripts is determined by a number of factors: sees). 1. First, by the implicit order declared in the According to the official documentation, V8 has run_at property in the manifest.json file. three different worlds: a main world, an isolated 2. If two or more extensions have the same run_at world and a worker world. A main world is where value, the browser tries to determine their exe- the original DOM with all its original scripts are cution order using the JavaScript event propa- executed. An isolated world is where the content gation mechanism [9]. scripts of the extensions are executed—all of them 3. Finally, if the event propagation order is the can access the main DOM through Blink C++ shared same, extensions are executed according to objects. Finally, a worker world is associated with their installation time: A executes before B if threads in such a way that each isolated world is as- B was installed after A. sociated with one worker, i.e., the main thread is the This pipeline works as follows. The content script main world plus each of the content scripts. Figure of the first extension is inserted and then it is exe- 2 represents how Chrome manages and isolates con- cuted in an isolated world by using the method ex- tent scripts of browser extensions. ecuteScriptInIsolatedWorld (see [5] for more details Overall, this isolation mechanism prevents about worlds in Chrome). The output of an exten- Chrome from being vulnerable to attacks such as the sion is automatically synchronized with the shared one recently demonstrated in [14] against Firefox, DOM, so when the next extension is executed its whose security model lacks isolation. Nevertheless, wrapper DOM already contains all the changes that Chrome’s security model has not considered privacy previous extensions have made. between extensions as part of its architecture. This allows, for instance, that if the Pinterest extension 3.1 Manipulating the execution inserts a element on each picture contained pipeline in the DOM, then all these changes will automati- cally be visible to the rest of the extensions, regard- We assume that the attacker gets one malicious less of whether they run in isolated worlds. This ob- extension at the end of the execution pipeline.
4 Even if the extension is not the last to be in- events in the browser (i.e., in the web page context). stalled, Chromium’s extensions model provides var- This guarantees that the extension will always be ex- ious mechanisms that an attacker can exploit to ecuted whenever any event is fired. modify the order in which parts of the extension The official extension of Pinterest, which has code will run. For example, a malicious extension more than 10M users, parses the entire content and can be marked to run once the DOM is loaded. This adds hidden elements on each picture it is achieved by setting the run_at property to doc- finds in the DOM, as well as some Cascading Style ument_end in the manifest.json file. Additionally, Sheets (CSS) elements. When the user triggers the the extension can use the capturing JavaScript event onmouseover() event by passing the mouse pointer propagation property to force that the fired event over a picture, the span becomes visible in the form would execute the extension in the return journey of of a button and, if the user clicks on it, the picture the event propagation (check [9] for further details is automatically shared on her Pinterest board. As- about this). Moreover, modifying the default execu- sume now that the user has some “secret boards” de- tion order could be done by following two different fined in her Pinterest account to avoid sharing pic- approaches: tures with all the world. Our malicious extension 1. Through another extension’s management per- can carry out the following actions: missions, similarly to what the Extensity ex- 1. It can add a listener to the same onclick() event tension does [4]. Essentially, this extension to know which pictures the user adds to her ac- enables and disables extensions automatically count, and thus the photos will no longer be pri- in the browser. The attacker will disable all vate. installed extensions and then re-enable them 2. It can learn what pictures the user likes and it again, but putting the malicious extension at the could share that information to an advertise- end. For this to work in practice, the user must ment company [19]. explicitly approve the malicious extension re- 3. It could generate a click JavaScript event on quirement to extend its permissions (namely, each picture, automatically sharing all pictures management). Since many users do not pay in the user’s account without any confirmation attention to requested permissions, this could pop-up. guarantee success for the attacker. 4. It can replace the picture the user wants to share 2. Modifying the Secure Preferences file. This by another one. is a JSON configuration file that was initially Evernote Web Clipper has currently more than thought to be modified only by the browser 4.5M users. The extension parses the web page and [1]. However, Chrome allows developers to inserts some CSS code and hidden elements distribute extensions as part of other software on each picture contained in the DOM. Additionally, so this file could also be externally modified by it adds a contextual menu when the user performs a other processes. This is the basis for most of right click either on a single tag or in the whole doc- the malware installed in the browser because ument. Using this contextual menu, the user can add of its deficient security [6]. The attacker can items such as meetings, personal notes, or any other thus modify the install_time property in the Se- information to her calendar. Our malicious exten- cure Preferences file, and put her extension at sion can subscribe to the click events and, in addition the end of the pipeline. See [16] for a detailed to the attacks described for the Pinterest scenario, it explanation on how to modify the manifest file. could also learn all details about the notes or calen- dar entries added by the user. 3.2 Attack examples Finally, we tested it againts vidIQ Vision for YouTube. This extension has more than 500,000 To exemplify the problem, we tested the attack users. Among other actions, it inserts a 5 asks her for her username and password (as a mat- only updates DOM, then fi(DOM) = DOMi where ter of fact, all extensions subscribed to either onkey- DOM is equal to DOMi except for the field that has down(), onkeypress() or onkeyup() events may get been updated.2 both the username and password). Our malicious We assume a tree operation that allows us to extension, apart from getting the username and pass- compare DOMs and give us the difference between word, could also get all viewed videos and profile them: DOM - DOM’. Moreover, we say that DOM the user’s habits. is smaller or equal than DOM’ (denoted DOM ≤ DOM’) if and only if DOM is a subtree of DOM’.3 3.3 Modeling extension effects Finally, we say that the default knowledge of an extension is the amount of information it can get Before formally defining our attacker model, we first from the DOM at the moment of its execution. Note introduce some notation and definitions. In what fol- that the actual knowledge of an extension might not 1 lows, E = hE1,...,Ei,...,Eni (n > 0) will de- be equal to the default knowledge. note the “set” of extensions already installed in the Definition 2. = h i browser, where the index indicates their default exe- Let E E1,...,Ei,...,En with 0 be as before, DOM the original content, and cution order (i.e., E is the first to be executed). n > 0 1 = { } When extensions are executed, they have an ef- EV ev1, ev2, . . . , evn the set of events that default knowledge fect. For our purposes, we split such effects into DOM0 can fire. We define the of an extension ( ) = { | ∃ ∈ two parts: a functional effect that is reflected on Ei as K Ei DOM0 e · = ()} ∪ { } 1 ≤ the changes done to the DOM the extension acts EV e load DOMi 1 for < i n, and ( ) = { } =− 1 on, and some side-effects that are not directly re- K Ei DOM0 if i . We say that an ex- knows at least as much as flected in the DOM (e.g., sending information to tension Ej extension Ei 1 ≤ ≤ ( ) ⊆ ( ) other servers, interacting with the browser, execut- ( i, j n) if and only if K Ei K Ej . We ing external scripts, etc.). The functional effect of also define an order between extensions concerning the DOM they have direct access to: v , if an extension E when applied to a DOM will be Ei Ej i and only if the resulting DOM after executing both denoted by f (DOM) = DOM . In this paper we i i ≤ are only concerned about the functional effect of extensions is such that DOMi DOMj. DOMs, so all the results that follow only apply to Note that the real knowledge of an extension what extension can do on the DOMs and, thus, no might not be equal (and neither a subset nor a su- claim is done concerning extensions’ side-effects. perset) of the default knowledge. The reason is that, Extensions can perform four different types of as we will see, this knowledge might be affected by high-level operations while being executed: inser- attacks or by a solution to those attacks. The concept tions, deletions, updates, and simply doing nothing. is in any case useful as it characterises what the ex- tension knows by default, if no external interference Definition 1. Let E = hE ,...,E ,...,E i with 1 i n is added to the expected behavior of how the browser n > 0, be the set of extensions that a browser has al- works. On the one hand, if we have an execution ready installed and DOM the original content pro- 0 pipeline such that the functional effect of all of them vided as input. We define the execution pipeline as is only insertions or doing nothing. We say that the the result of the execution of the n extensions as execution pipeline is monotonic with respect to the composite functions: f ◦...◦f (DOM ) = DOM . n 1 0 n structure of the DOM (or simply, that it is mono- DOMs can be seen as trees [2]. We will use this tonic). We have then the following proposition con- fact to define the above operations in terms of oper- cerning monotonic execution (sub)pipelines. The ations on trees. Thus, if extension Ei only inserts el- proof is trivial. ements in the DOM, then fi(DOM) = DOMi where Proposition 1. Given a sequence of extensions hE1, DOM is a subtree of DOMi. In case Ei only deletes ... , Ej,...,Eh,...,Eni (with n > 0) such that something from DOM, then fi(DOM) = DOMi, 2 where DOMi is a subtree of DOM. Finally, if Ei Note that, to avoid over-formalization, we are not giving for- mal definitions for these operations in terms of trees as they are 1All the discussion below assumes that there is at least one rather intuitive. extension installed. 3We define <, >, and ≥ as expected. 6 the subsequence hEj,...,Ehi is monotonic, then However, this attacker will know neither the num- Ei 1 v Ei for j < i ≤ h. ber of extensions nor which operations they have − performed over the content. Note that the gain of If an execution pipeline is such that the overall knowledge is not much over previous extensions ex- functional effect of all extensions is only insertions cept if DOM u is part of a monotonic subsequence or doing nothing, we say that the execution pipeline A (cf. Proposition1). is monotonic with respect to the structure of the An interesting consequence of our threat model is DOM (or simply, that it is monotonic). Conversely, that all extensions which are installed on the browser if any extension E in the execution pipeline deletes i are potential usual attackers because they might have or updates information, then it is generally impossi- access to the original DOM and to the input DOM ble to make any statement about whether any other received from the previous extension in the execu- extension knows more or less than E . For instance, i tion pipeline (cf. Definition2). an extension Ei 1 could delete something while ex- tension E adds− it back, in which case any other ex- Remember that despite our proposed attack might i be performed without exploiting the order, i.e., a tension Ej (j > i) will not be able to detect that there has been a deletion in the past. malicious extension could subscribe to all possible events in the DOM, the amount of needed source code to tackle all possible privacy attacks would be 3.4 Attacker model incredibly huge and infeasible due to the amount of We consider two different types of attackers: strong possible extensions and attacks. and usual attackers. Intuitively, a strong attacker is In this work, we remark the existence of this se- a malicious extension that has access to the output of curity threat which is transparent even for the au- all executions in the pipeline. Note that this provides tomatic static analysis of the source code that offi- the attacker not only with the effect of all extensions, cial repositories perform [8]. Notice that by using but also with knowledge about which extension did our attack, the simplest dummy extension installed what. Alternatively, a usual attacker is a browser just after, for instance the official Pinterest exten- extension that only has access to the corresponding sion, would detect the existence of the former one DOM that the extension receives as input when it is and thus, it can communicate to an external server executed (plus the original DOM). More formally: to retrieve the customized exploit performing thus an adaptive attack. Definition 3. A strong attacker (As) is an exten- Additionally, our scenario can handle situations sion E s that is interleaved in the execution pipeline A where, two browser extensions developed by the such that f s ◦fn◦f s ◦· · ·◦f s ◦f1◦f s (DOM) = A A A A same person or company but placed for instance DOMn. This is the strongest attacker because it at the beginning and at the end of the execution can know all the changes that all extensions have queue will actually access to different information performed. A usual attacker (Au) is an extension and thus, collaborate to perform attacks like browser E u that is executed in the j−th position of the A hijacking [19, 13], or fingerprinting [15, 10] attacks. pipeline (j ≤ n) such that fn ◦ ... ◦f u ◦ · · · A ◦f1(DOM0) = DOMn, having the default knowl- edge any other extension in position j could have. 4 Our solution Note that j > 1 as otherwise the attacker would learn nothing. Our solution introduces the notion of a monitor ex- A strong attacker has definitively more knowl- tension, whose goal is to prevent regular extensions edge than any other in the pipeline and can thus from learning from each other. Intuitively, monitor take advantage of that. Note that, in particular, a extensions are used to detect all changes that an ex- strong attacker gets to know which extension did tension makes; log those modifications; delete them what changes since it can calculate the effect of each from the DOM passed on to the next extension in the extension. The usual attacker can only infer par- execution pipeline; and, at the end of the pipeline, tial information about the other extensions by diff- merge all changes to produce a final DOM. Figure3 ing DOM0 and the DOM u that it receives as input. shows the four main components of our scheme: A 7 DOM0 DOMn 1 DOMn+1 E1 EN Apply same content directly by using the XMLHttpRequest DOM1 DOMN JavaScript object, but the received DOM could be completely different from the current DOM because Diff Del Diff Del of that browser pre-processing. Store After that, the output of the initial extension DOM0 and the rest of the DOMs wrappers are syn- Figure 3: Architecture of our solution and its four chronized. At this point, the first official extension main modules. is run and may perform some actions over the con- tent. The resulting (DOM1) is the input to the next monitor extension, plus the initial DOM (DOM0) • The Diff module takes a pair of DOMs (namely, needed to get the difference between both DOMs: (DOMi 1, DOMi) and performs the difference Diff=DOM1-DOM0. All the possible resulting val- − between them (Diff=DOMi - DOMi 1). ues of this operation are stored (Store) for the fi- • The Store module is shared between− all moni- nal post-processing (patch operation), and the dif- tor extensions and collects all changes in a ta- ference Diff is then removed from the output of the ble. This table can be seen as a patches table extension DOM1. It is worth noting that this new with the following format: ◦fEinitial (DOM0) = DOMn. The information flow same). In some sense, we do want to make sure that is as follows. Assume that Alice accesses a web the order of execution is irrelevant with respect to page. The browser requests the URL and, once the the knowledge the extensions should get (i.e., not ac- DOM0 tree is retrieved, the first isolated world cor- cessing sensitive information they are not allowed to responding to the initial extension (Einitial) is exe- as an effect of this information being passed by other cuted. This first extension is not part of the general extensions), but we also know that the outcome of solution (see Figure3), but we found out that, when the executions of such extensions might be modified we tried to implement it in a real setting, it is needed by our approach eventually modifying some of the because Chrome—and other browsers in general— expected output. Let us consider an example show- do some pre-processing to the DOM (e.g., closing ing the possible effects of our solution. Let Ei be an forgotten open HTML tags, adding some mandatory extension that changes the DOM’s background color HTML tags or changing everything into lower case). to black (let us assume the original color was white This initial extension does not add any changes to and that there is text both in black and blue). Let the DOM. We note that an extension can request the us consider that a later extension in the execution 8 pipeline, Ej (1 ≤, i < j ≤ n) changes the back- tion? One may think that a strong attacker could at- ground color to white. It is clear that in the current tack our solution by interleaving extensions between order, the final outcome is that the DOM’s back- our monitor extensions (before and after) thus by- ground color is white and all the text is readable. passing our protection in order to get access to the That being said, it is clear that in case the extensions effects of the installed extensions before being mod- were executed in different order (first Ej and then ified by our monitor extensions, and then restoring Ei) the outcome will be very different: not only the it after our modification. To do so, the attacker must background will be black (instead of white), which create an extension with the management privileges. by itself does not seem to be a big deal, but more That, however, would only be possible if the user importantly there will be some text not visible to the explicitly grants that permission to the attacker. The user. This not only affects the usability of the DOM best we can do is then to show a warning message (the black background will hide all the black text so to the user as soon as we detect the presence of such the user will not be able to see it), but may intro- malicious extension and rely on that the user blocks duce some security issues (the hidden text might be the attacker. If the user grants the permission, we are clicked accidentally producing undesired effects). thus vulnerable to the attack. In order for our pro- This is however, an inherent behavior of the posed solution to be able to detect the presence of browser and our proposed solution does not mod- such attacks our extension would need to have man- ify the default behavior of the browser, i.e., a given agement privileges. This could only be granted by HTML content looks the same with a set of ex- the user at installation time. tensions enabled and with the same set and the Proposition 2. Our extension-based solution is ro- proposed solution. Moreover, JavaScript periodi- bust against strong attackers under the assumption cal tasks such as setInterval(callback, delay) are not that our (initial, middle and final) monitor exten- covered in detail with our solution. This method sions are given management privileges, and that the automatically enqueues the function defined in the user does not explicitly give management privileges callback in the task queue. For instance, if the ex- to the attacker. tension A uses this method to get all password fields from the page the user is visiting each 2 seconds. In case the user (accidentally or consciously) This is a completely different scenario because the gives the needed privileges for a strong attacker to execution of this task cannot be controlled through install his extensions, our solution would be able to JavaScript code alone. detect that and communicate it to the user. Indeed, Does our solution indeed mitigate possible at- a strong attacker would need to install n + 1 exten- tacks? According to the definitions given in Sec- sions interleaved between any two extensions, and tion3, the knowledge of an extension executed in our monitor extensions would be able to detect that. position j (1 < j ≤ n) is the same knowledge So, we have a way to detect this issue, notify it, and as the previous extension (Ej 1) in the pipeline ask the user to uninstall the extension. Besides, by − plus the actions that Ej 1 performs over the DOM identifying this we would be able to keep a black list − (DOMj 1 ∪ DOMj). On the contrary, when we of malicious extensions. − measure the knowledge of an extension with our so- Finally, it is worth mentioning that most of the lution, it is thus decreased to DOM0 (given that our aforementioned questions would be solved by mod- solution only passes the original DOM to each ex- ifying the Chromium’s source code. Note that an tension). Our solution also mitigates a strong at- attacker might insert as many extensions as desired tacker by limiting what she gets to know in the same and could even alter the execution order. By modi- way as for the usual attacker: our interleaving guar- fying the source code, all extensions receive a fresh antees that a strong attacker only gets to know the copy of the original HTML and, thus, no-one will original DOM. The reduction in knowledge is of learn about the actions executed by other extensions. course more significant than in the usual attacker This solution uses a similar approach but requires (Section3). modifying (and recompiling) the core of Chromium How robust is the approach? That is, can we guar- to achieve a real isolated execution. At a logical antee that a strong attacker cannot bypass our solu- level, it works exactly the same as the general so- 9 #Extensions Originally Solution #Extensions Originally Solution lution depicted in Figure3. 2 217,9Kb 255,0Kb 7 420,9Kb 513,1Kb 3 331,6Kb 379,7Kb 8 492,0Kb 595,2Kb 4 348,7Kb 407,9Kb 9 504,3Kb 618,5Kb 5 374,1Kb 444,2Kb 10 527,1Kb 652,3Kb 6 392,1Kb 473,3Kb 5 Experimental results Table 1: RAM Consumption We have studied the following performance indica- tors according to [7] as well as the W3C consortium extension experiment means that only the 5 origi- [17]: 1. memory consumption; 2. time needed to nal extensions are installed in the browser. Addi- parse the HTML; 3. when the onLoad event is fired tionally, for all the experiments we have measured (many JavaScript files wait for this event); 4. the times without the browser’s cache and by launch- processing time which means that all resources have ing one new, fresh instance per experiment, i.e., we been loaded (DOM is completed i.e., the loading have closed and opened Google Chrome each time spinner has stopped spinning), and; 5. a final test we added a new browser extension to measure RAM to show the total time that Chrome needs to gen- consumption and user experience times. erate the onLoad event, i.e., the page is ready. All the experiments but the memory consumption were carried out accessing the Alexa’s Top 30 web sites 5.1 RAM Consumption and averaging the results over 50 runs. Additionally, To measure memory consumption, we have used the in order to measure all the time-based metrics, we developer tools provided by Chrome. Table1 shows have used the DevTools profiling tools provided by the impact on the browser performance in terms of the browser. RAM consumed in KB. We have isolated the execu- Our extension based solution inserts a middle tion of the original extensions and the monitor ex- monitor extension between every two original ex- tensions in order to show that the impact of our pro- tensions, plus the initial and the final ones. Thus, posed solution is almost negligible in comparison to the number of total extensions is 2n + 1 (n original the performance of the original extensions. More- extensions plus n + 1 added monitor extensions, in- over, both the initial and the final extension consume cluding the initial and final ones). In order to test 13 KB of RAM each, whereas our monitor exten- what impact these additions have on both Chrome’s sions consume 11 KB of RAM on average. These performance and the user experience, we have in- extensions differ considerably from extensions such stalled a set of original extensions in a MacBook Air as AVG Web TuneUp, AdBlock or Ad Block Plus, with 2.2 GHz Intel Core i7 CPU and 8 Gb of RAM. which consume 27.6 KB, 190.3 KB, and 11.3 KB The Chrome version where all test have been run is of RAM on average, respectively. Note that the size 60.0.3112.78 (Build official) (64 bits). We used the of such extensions depends in fact on the content of 10 most downloaded browser extensions from the the web page. For instance, a page containing a sub- Chrome Web Store, since according to [11], the av- stantial amount of advertisements would make Ad erage number of installed extensions per user is 5. Block to consume much more memory. From the All figures related to the monitor extensions de- results we can conclude that the impact of our solu- pend on the number of original extensions installed tion is approximately linear in the number of exten- in the browser (2n + 1). In our experiments, the sions. More concretely, our proposed solution de- number of extensions is related to the original ex- creases performance by a factor of 1.15 per installed tensions installed. This number varies if the exper- extension in terms of RAM. iment is performed by using the original extensions or our proposed solution. For instance, when we 5.2 Impact on user experience say that with 5 extensions it takes 1.3 seconds to load all the scripts of a entire page, it means that Figure 4a shows the time that Chrome needs to parse in reality there are 11 extensions installed in the the HTML. At this point, Chrome has already parsed browser: 5 original extensions, plus 4 middle ex- the entire HTML file and creates the DOM. We can tensions, plus 1 final extension, plus 1 initial exten- observe that, in the worst case (for 10 original exten- sion. On the contrary, 5 extensions on the original sions), our solution introduces a delay of 5000ms. 10 Original Extensions Original Extensions 5000 Proposed Solution Proposed Solution 80 4000 60 3000 40 time in ms time in ms 2000 20 1000 0 0 0 1 2 3 4 5 6 7 8 9 10 0 1 2 3 4 5 6 7 8 9 10 number of extensions number of extensions (a) HTML Parse (b) onLoad Original Extensions Original Extensions 17500 17500 Proposed Solution Proposed Solution 15000 15000 12500 12500 10000 10000 time in ms 7500 time in ms 7500 5000 5000 2500 2500 0 0 0 1 2 3 4 5 6 7 8 9 10 0 1 2 3 4 5 6 7 8 9 10 number of extensions number of extensions (c) Processing Time (d) Total Time Figure 4: Evaluation of our proposal according to W3C parameters 11 Similarly, Figure 4b shows the time needed for the extension in the pipeline and produce many copies browser to fire the event onLoad. This event is crit- interleaving itself in between all other extensions. ical because most of the extensions, jquery, and all In this way, it could be possible to get to know what libraries based on jquery wait for that event to be ex- all other extensions are doing and exploit this fact. ecuted. From the results it is remarkable that the in- We have shown examples on how to perform both a clusion of our solution does not introduce undesired usual and a strong attack. delays in the execution of this event in comparison We have provided a proof-of-concept to address to the default behavior. this problem which relies on replacing the pipeline The processing time measures when all resources execution model by one in which each extension ex- have been loaded. Currently, the way the user knows ecutes in isolation, and then combine all individual when a given page has been totally loaded is when effects to create the final DOM. Our implementation the spinner at the core of most browsers stops spin- does this through a set of monitor extensions. As a ning. There are a bunch of external parameters that first approach we decide to take the effect of the last directly affect this time, such as the network over- extension in the pipeline. We could, however, easily head or the number of resources previously stored provide a solution based on user intervention (ask- in the cache, among many others. All in all, we ing the user to decide) or to apply a different pol- can conclude that the number of installed extensions icy (choose the first one, or non deterministically). has a potentially large impact on performance and, A more refined way to do so is left as future work therefore, in the processing time as it is depicted in (e.g., one could gather information on how harmful Figure 4c. This, however, is only relatively critical the effects are, rank them and choose the less harm- as the average number of installed extensions is very ful using machine learning algorithms). low for most users. Finally, Figure 4d shows the time needed to load the whole web page. The total time is calculated Acknowledgments from the sum of processing and load times. This plot, together with the ones discussed before, show This work was partially supported by the the that content scripts of browser extensions are not Swedish Research Council (Vetenskapsrådet) totally decoupled from the rendering process and, through the grant PolUser (2015-04154), the therefore, they directly impact performance and user Swedish funding agency SSF through the grant experience. Data Driven Secure Business Intelligence, the In general, our solution increases very moderately Spanish Goverment through MINECO grant the amount of time Chrome needs to render the con- SMOG-DEV (TIN2016-79095-C2-2-R) and by the tent. This problem might be solved by modifying Regional Goverment of Madrid through the grant the browser’s source code. CIBERDINE (S2013/ICE-3095). 6 Conclusions References [1] Chrome. External Extensions. In this paper we have discussed one important secu- https://developer.chrome.com/ rity and privacy implication of Chromium’s exten- extensions/external_extensions, sion model: the effects of one extension are visible 2018. to others in the execution pipeline. This can be ex- ploited by a malicious extension that can, for exam- [2] W3C DOM Technical Committee. W3C ple, get access to sensitive information or manipu- DOM4. https://www.w3.org/TR/ late the DOM elements introduced by other exten- domcore/, 2018. sions. We call this a usual attacker, in contrast to a strong attacker who has access to the effect of each [3] Jake Archibald. Google Chrome Developer. single extension in the execution pipeline. A strong Tasks, microtasks, queues and schedules. attacker may, in particular, install itself as the last https://jakearchibald.com/2015/ 12 tasks-microtasks-queues-and-schedules/browser, security in the modern era: New data- 2018. only attacks and defenses. In EuroS&P, pages 366–381, April 2017. [4] Extensity. Extensity. https: //chrome.google.com/ [14] Anil Saini, Manoj Singh Gaur, Vijay Laxmi, webstore/detail/extensity/ and Mauro Conti. Colluding browser extension jjmflmamggggndanpgfnpelongoepncg, attack on user privacy and its implication for 2018. web browsers. Computers & Security, 63:14 – 28, 2016. [5] Google. Design of V8 bindings. https://chromium.googlesource. [15] Alexander Sjösten, Steven Van Acker, Pablo com/chromium/src/third_party/+/ Picazo-Sanchez, and Andrei Sabelfeld. La- master/WebKit/Source/bindings/ tex gloves: Protecting browser extensions core/v8/V8BindingDesign.md# from probing and revelation attacks. Power, World, 2018. page 57, 2018. [6] HMAC. Chromium Secure Prefer- [16] Tigzy. Adlice Software. Chrome Secure ences. http://www.adlice.com/ Preferences Modification. https://cs. google-chrome-secure-preferences/, chromium.org/chromium/src/rlz/ 2018. lib/machine_id.cc?sq=package: chromium, 2018. [7] Ilya Grigorik. Measuring the Crit- ical Rendering Path. https: [17] W3C. Navigation timing. https://www. //developers.google.com/web/ w3.org/TR/navigation-timing/, fundamentals/performance/ 2018. critical-rendering-path/ measure-crp, 2018. [18] w3schools. Browser Statistics. https: //www.w3schools.com/browsers/, [8] Nav Jagpal, Eric Dingle, Jean-Philippe Gravel, 2018. Panayiotis Mavrommatis, Niels Provos, Mo- heeb Abu Rajab, and Kurt Thomas. Trends and [19] Xinyu Xing, Wei Meng, Byoungyoung lessons from three years fighting malicious ex- Lee, Udi Weinsberg, Anmol Sheth, Roberto tensions. In USENIX, pages 579–593, 2015. Perdisci, and Wenke Lee. Understanding malvertising through ad-injecting browser [9] JavaScript. Bubbling and captur- extensions. In WWW, pages 1286–1295, 2015. ing. https://javascript.info/ bubbling-and-capturing, 2018. [10] Pierre Laperdrix, Nataliia Bielova, Benoît Baudry, and Gildas Avoine. Browser finger- printing: A survey. 2019. [11] Mozilla Add ons Blog. How many firefox users have add-ons installed? https: //blog.mozilla.org/addons/2011/ 06/21/firefox-4-add-on-users/, 2018. [12] Chromium Projects. Chromium. https:// www.chromium.org, 2018. [13] R. Rogowski, M. Morton, F. Li, F. Monrose, K. Z. Snow, and M. Polychronakis. Revisiting 13