Presenting CrossFire at Black Hat Asia 2016

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.

Extension Vetting

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.)

Now, manual vetting has definite drawbacks. Humans are fallible and make mistakes, and much security research therefore focuses on automating whenever possible. However, JavaScript is a notoriously difficult language to automatically analyze, and most efforts in this space have focused on some form of sandboxing instead. Since the Firefox extension API was developed before JavaScript sandboxing began to be seriously investigated, sandboxing approaches cannot be applied in a straightforward way. Thus, manual analysis is the most practical remaining option.

Extension Reuse

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 executable (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 get_url, save_file, and 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. Think return-into-libc, but with JavaScript and extensions – that’s the essence 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.

What Next?

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.

What’s potentially of greater concern is that JavaScript is used in more places than ever today. JavaScript frameworks that allow co-mingling of untrusted third-party code might also be vulnerable to similar code reuse attacks, and novel defenses will be required to address these threats.