Ahmet and I will be presenting CrossFire at Black Hat Asia in Singapore in March. CrossFire is a new attack against Firefox that leverages extension reuse to bypass the extension vetting process, which is the main line of defense against malicious Firefox extensions.
The lack of isolation between extensions and failure to enforce least privilege in Firefox is a well-known problem. We’ve published before on defending against malicious extensions, and one of Chrome’s selling points is its extension security architecture that pointedly improves on Firefox’s model. Mozilla has now engaged in multiple efforts to migrate developers away from the classic extension API – first, with JetPack, and now with WebExtensions. This, however, has been an uphill battle.
If extensions have full access to a powerful API, what prevents attackers from abusing this power? The answer is manual vetting. That is, to publish an extension in the Mozilla Add-Ons directory, developers must submit their extension for code review and testing. As part of this review, experienced vetters check the extension’s code for malicious behavior. (Unfortunately, no explicit checklist for this review process is publicly available.)
An obvious assumption that vetting relies upon is that reviewers will be able to find evidence of malice in extensions. Of course, it might be the case that an extension is large and complex, and some subtle malice might escape attention. Attackers could also choose to explicitly obfuscate their malware, although standard obfuscation techniques tend to be noisy.
But, what if a malicious extension did not actually contain any malice? This seems like a contradiction, but we show using CrossFire that we can closely approximate this idea with extension reuse.
Consider a scenario where a user has unwittingly installed a malicious
extension that wishes to download and execute a native executable – i.e., a
dropper. That extension will necessarily include code that uses the Firefox
extension API to download the executable (
get_url), more code to save that
executable to the filesystem (
save_file), and finally code to launch the
exec_file). The hope is that a vetter will manage to identify
these malicious uses of the extension API.
Now, consider this alternate scenario. Instead of directly including code that
invokes sensitive extension APIs, a malicious extension could find and reuse
suitable code in other, benign extensions. In this example, a malicious
extension finds and executes semantic equivalents for
exec_file in WoT, Adblock Plus, and Firebug. These equivalents are
present because each extension legitimately needs to invoke this sensitive
functionality. However, thanks to the lack of isolation between extensions in
Firefox, the malicious extension can abuse this functionality indirectly.
of the CrossFire attack.
In fact, our implementation of CrossFire can semi-automatically produce working extension reuse exploits using a lightweight static analysis. While neither sound nor complete, this analysis is often successful at producing an end-to-end exploit, or at least a partial exploit that can be tuned by the attacker.
In the end, yes, the extension still contains malicious logic. But, it becomes much harder to detect, as now an extension vetter cannot rely on tracing backwards from uses of privileged APIs, but must now reason about the entire extension and, in particular, whether all variables can ever reference a privileged object or function – either directly or indirectly.
CrossFire clearly makes extension vetting, already a tedious and error-prone process, more difficult and less effective. The silver lining in this story, hopefully, is that Mozilla can convince developers to swiftly move to WebExtensions. The prior, failed effort to migrate developers to JetPack does not bode well, however. In the meantime, CrossFire will remain a relevant attack.