CrossFire: An Analysis of Firefox Extension-Reuse Vulnerabilities
Engin Kirda from Northeastern University came to MIT to talk about recent work from his lab regarding Firefox extension-reuse vulnerabilities. I will outline the talk and work here, but for more information and details, I encourage you to check out their recent NDSS paper.
Firefox is an open source web browser with over half a billion users. One feature of this browser is the extensions, which provide new capabilities and allow for customization. There are about 15,000 extensions currently available, and the popular extensions have millions of users. However, this makes them a target for attackers.
In the Firefox legacy extension architecture, there is a shared Javascript namespace, which allows extensions to read, write, and modify objects or variables of others. Similarly, there is a shared window and no privilege separation.
Browsers are an attractive target because extension authors are untrusted, vulnerable extensions can be exploited, and malicious extensions are a real threat. The current protections are to enforce browser marketplaces for extensions where they are audited through various means and “vetted.” Moreover, extension isolation provides least-privilege and policy-based enforcement.
In 2009, an add-on SDK, aka Jetpack, was introduced to isolate extensions from each other. It also separated content and core scripts and implements least privilege. However, adoption has been very slow, and it has been superseded by WebExtensions.
Lack of isolation leaves legacy extensions defenseless against capability leaks. Attackers can stitch together exploits by abusing capabilities. The more power the vulnerable extensions have, the easier it is for an evil extension to attack a user. Here is an attack example:
This leads to their work, Crossfire, which help identify vulnerabilities in Firefox extensions. There are two main stages in Crossfire. The first stage is the vulnerability analyzer. It finds sinks (sensitive functions), identifies sources (global variables and functions), and generates a call graph. Then, the second stage is taint analysis. It finds paths from sources to sinks and does taint analysis on these paths. Finally, it produces a vulnerability report.
Next is exploit generation. It targets global functions and its parameters, security sensitive functions, and globals that taint the parameters of these functions. For exploit rules, it is defined for each sink, sets the global variables and parameters, and calls the target function. Finally, the output is an automated attack or a manual attack (attack template for rapid development).
The static analysis and exploit generation are also very fast. For more results and specifics on CrossFire, I refer you to their paper. This work is very impressive and has generated impact already. They have talked to Mozilla’s security team, who have acknowledged the problem and are trying to evolve their extensions platform to integrate greater security measures for the future.
