Roberto Suggi Liverani and Nick Freeman, security consultants with security-assessment.com have discovered that poorly-written Firefox extensions can be exploited to install malware on a victim’s computer. It seems Mozilla does not have any security requirements for extensions. That’s a problem, as their flagship Web browser Firefox implicitly trusts extension software.

I first learned about the problem when I read the two researchers’ Defcon 17 presentation, “Abusing Firefox Extensions” (pdf). The possibility of vulnerabilities in extensions concerned me, having just finished the article, “10 Firefox extensions that enhance security“. I certainly did not want to promote extensions that are vulnerable.

To the best of my knowledge, the extensions in my article are not buggy. Because I am in the process of writing an article with 10 more security extensions, I will be checking with Mr. Suggi Liverani and Mr. Freeman to make sure all the extensions I refer are beyond reproach.

Confusion about add-ons

Mozilla and extension developers tend to confuse terms by generically calling extensions, add-ons. They are add-ons, but it is important to know that plug-ins are add-ons as well. The main difference being, plug-ins are automatically installed. This article is about extensions, but you can learn about plug-ins and their problems in “Firefox Plug-ins: What are they?“

What are extensions

Developers at Mozilla work hard to keep code for the Firefox Web browser to a minimum. That is a good thing. It reduces complexity, bugs, and allows Firefox to load quickly. The flip side of a minimal foot print is leaving users wanting additional features to make surfing easier and more enjoyable. Enter extensions — they give Firefox increased extensibility or the ability for users to add features of their choosing.

What Mr. Suggi Liverani and Mr. Freeman found

The researcher’s presentation was exemplary, explaining in detail how weak extensions are exploited. The presentation also gave several examples of questionable extensions and how they are exploited. Two of the better-known extensions examined were CoolPreviews and FireFTP.

After reading the presentation, I was confused about a few things. On the off chance, I sent both gentlemen an e-mail message containing a list of questions. They were kind enough to answer the questions, and I would like to pass that information on:

Question 1: How did you discover vulnerabilities in Firefox extensions?

We were auditing a large web application which included a tailored-Firefox extension. That was the first time and we suddenly realized we had to include the extension in the testing scope. Also, we were playing with other extensions (Skype and InfoRSS) and we felt there could be bugs in those extensions as well.

Question 2: Could you please explain how the exploit works?

There are many ways a vulnerable-Firefox extension can be exploited. This really depends on the nature of the vulnerability. An input-based vulnerability such as Cross Site Scripting has significant consequences in extensions, especially when malicious code can be executed from the chrome:// zone.

Question 3: You mention that Chrome plays a big role in this exploit. What is Chrome and what part does it play?

In our presentations, we refer to Chrome as the chrome:// zone where the extension’s code runs (chrome privileges are trusted by Firefox). Chrome privileges allow extensions to do basically anything with the OS by querying/interacting with Firefox core functionality provided by XPCOM libraries/interfaces.

Question 4: Could you explain the comment: “Any input rendered in Chrome is an XSS injection point”?

What we mean is that if you have in injection point in the chrome:// zone, then it is game over. The injection can include arbitrary browser-based content which has chrome privileges. This allows exploitation of Firefox extensions as shown in the following slide.

Question 5: Your presentation mentions that NoScript is rendered useless by this exploit, could you explain how?

NoScript is a security extension and protects the user when browsing untrusted content (e.g. Internet). The misconception is that NoScript can protect you from vulnerable extensions. The chrome:// URI scheme is whitelisted in NoScript, as most extension code needs to run with chrome privileges to provide functionality. For example, an extension that shows the content of your C:\ Folder needs chrome privileges to interact with the file system. NoScript cannot block chrome:// as that will break Firefox and extension functionality.

Question 6: You state that running Firefox in Safe-mode is the only sure-fire cure at this time. Why can’t extensions just be removed?

Extensions can be removed. That line is more a security policy in a corporate/company environment where Firefox is used. An administrator should set Firefox in Safe Mode so users cannot install extensions. This needs to be weighed on a per-case basis, as using Safe Mode means you can’t run NoScript, so normal browsing becomes less secure.

Recommendations

Mr. Suggi Liverani and Mr. Freeman have come up with the following recommendations for developers, security professionals, and end-users:

Developers

Security professionals

  • Adhere to the OWASP testing guide.
  • Watch publications for new ideas on just-released extensions.

End-users

  • Don’t trust extensions.
  • Check Bugzilla for new information about extension-security issues.
  • Make sure extensions are up-to-date.
  • Consider Safe Mode, as it disables all extensions.

Final thoughts

The fact that Firefox extensions are vulnerable, was not on my radar. Not until I read about the work being done by Mr. Suggi Liverani and Mr. Freeman. The researchers are in contact with Mozilla, and Mozilla has acknowledged this problem. If Mozilla’s past performance is any indication, there should some sort of solution shortly.

I would like to thank Roberto Suggi Liverani and Nick Freeman for their effort and willingness to explain the intricacies of extension vulnerabilities.