Communications - September 2011

extension. The values are either stored in the preferences or in a local file. Since we trust the users and extension developers in our trust model, these extensions are considered to be non-vulnerable. However, if the preferences file or the local file system is corrupted in any way, these extensions can be attacked.

The fifth column shows the extensions where the source is code from a Web site, and where an attack is possible provided the Web site can be attacked. In other words, these extensions rely on a trusted Web site assumption (e.g., that the code on the Facebook Web site is safe). We think that these are valid warnings that users of an extension (and Mozilla) should be aware of; trusted Web sites can after all be compromised, and the code on these sites can be changed leading to an attack on all users of such an extension.

Not all flows lead to attacks—the next set of columns describe the alerts that we were unable to convert to concrete attacks. Some extensions were not exploitable as the input is sanitized correctly (either by the extension or the browser), preventing JavaScript injection. Other extensions were not exploitable as the sinks were not in chrome executable contexts. These extensions are noted in the next two columns. Finally, Vex, being a static flow-analysis tool, does report alerts about flows that do not actually exist—there were very few of these, and are noted under the column “Nonexistent flows.” Section 5. 4 discusses the flows that do not lead to attacks.

new vulnerabilities discovered: The number of security vulnerabilities discovered is shown in column 3 in Figure 5, of which 7 are new. Wikipedia Toolbar versions V-0.5.7 and V-0.5.9 have flows from window.content.document to eval, which leads to attacks. Mouse Gestures Redox v- 2.0.3 has flows from nsIPrefService to eval, which also led to an attack. Beatnik V- 1. 2, Fizzle v-0.5.1, and Fizzle v-0.5.2 are also attackable, and have flows from nsIRDFService to innerHTML. Kaizou v-0.5.8 has a flow from window.content.document to innerHTML which leads to attacks. Section 5. 3 gives some details about the flows and the attacks in some of the vulnerable extensions. Details about Fizzle (and Beatnik) vulnerabilities can be found in the previous version of this article. 2 Known vulnerabilities detected: Apart from the new vulnerabilities found by Vex, there are several extensions that have been reported to be vulnerable in the past. In the course of our research, we found 18 unique extensions that were reported to be vulnerable in various databases like CVE, Secunia, etc. Of these 18, we did not find the source code for 5 extensions (Greasemonkey v≤ 0.3.5, Wizz Rss v < 3. 1.0.0, Skype v ≤ 3. 8.0.188, MouseoverDictionary v< 0.6.2, POW v < 0.0.9), so we did not analyze them. Of the remaining 13 extensions, we found that 10 of them can potentially be found using explicit information flow analysis techniques, like Vex.

Currently, Vex can detect 5 of the above 10 known extension that have flow-based vulnerabilities: Fizzle v-0.5, Beatnik V- 1.0, CoolPreviews v- 2. 7, 2. 7. 2, infoRSS V-<= 1. 1. 4. 2, and Sage v- < 1. 3. 9, <= 1. 4. 3. CoolPreviews has flows from document.popupNode to

appendChild. infoRSS has flows from nsIRDFService to appendChild. Sage has flows from BookmarksUtils to an object accessing the local file system using the nsI-File interface.

The remaining five extensions have flow vulnerabilities but were not found by Vex for the following reasons. For FeedSidebar v< 3. 2, FireBug v- 1.01, Scribefire v<= 3. 4. 2, and Update Scanner V< 3.0.3 the trigger of the flow was in an event handler or a function call which was called outside the extension’s code base. In Yoono version ≤ 6. 1. 1 an un-sanitized JavaScript element like an image or link is rendered in the chrome context. However, it was difficult to find the source and sink objects from its source code.

Finally, there were three extension vulnerabilities (for which we had the source) that cannot be found by Vex because they are not flow vulnerabilities. These vulnerabilities include attacks on a file server (e.g., FireFTP V < 0.97.2, < 1.04), and directory traversal attacks (e.g., Navigational Sounds version- 1.0.2, Ajax Yahoo Mail Viamatic Webmail version-0.9) when a chrome package is “flat” rather than contained in a jar. In both the above cases, an attacker can escape from the extension’s directory and read files in a predictable location on the disk. Since such attacks are not related to chrome privilege escalations, and Vex does not handle them.

5. 3. successful attacks

attack scripts: All our attack scenarios involve a user who has installed a vulnerable extension who visits a malicious page, and either automatically or through invoking the extension, triggers script written on the malicious page to execute in the chrome context. Figure 6 illustrates an attack payload that can be used in such attacks: this script displays the folders and files in the root directory.

The attack payloads could be much more dangerous, where the attacker could gain complete control of the affected computer using XPCOM API functions. More examples of such payloads are enumerated in the white-paper given in Freeman and Liverani7 In this section, we illustrate a few