Security

Mandatory Firefox extension signing

Mozilla recently announced a plan to roll out a cryptographic signature framework for Firefox extensions in the coming months. The system is designed to clamp down on so-called "gray area" extensions that, while far from falling under the traditional definition of malware, make dubious and shady changes to the way a user's browser functions. The change will mark a significant shift for Mozilla, which, in the past, has taken a wide-open approach to extension development and installation. But the new system will be mandatory: after a transition period, Firefox will not run extensions that have not been signed by Mozilla, and all extension developers will need to submit their extensions for a test that checks for bad behavior. Naturally, not all extension developers are happy about how that will affect their workflow, but Mozilla insists it is the option that best balances protecting users and encouraging extension development.

The announcement was posted by Mozilla's Add-ons Developer Relations Lead, Jorge Villalobos. He listed several types of malicious behavior commonly found in the gray-area extensions: altering the user's homepage, changing the browser search behavior, injecting ads into pages, and injecting scripts into social media sites. The extensions in question typically make these changes in secret, often under the guise of doing something else. Many present themselves as toolbars of one form or another; others get side-loaded, surreptitiously, when the user runs an installer or updater for some unrelated piece of desktop software.

In the past, Mozilla attempted to curtail such extensions by publishing a set of public guidelines for acceptable add-on behavior, and blocking extensions that violate the rules. That strategy may have scaled as far as it can, though—the blocklist is quite long, and developers have taken to new strategies to evade it, such as randomly generating a different extension ID for every copy.

The plan

Preventing bad behavior in extensions is more difficult in Firefox than in other browsers like Chrome or Apple's Safari, Villalobos said, for two reasons: first, Mozilla intentionally allows its add-ons to alter more browser functionality than the competing browsers do, and second, because Mozilla does not act as the central distribution point for add-ons. Anyone can publish and distribute a Firefox extension from any site.

Finding a way to curb gray-area extensions without acting as the final gatekeeper for extension publication was the issue. As Villalobos explained, the plan that emerged after many months of discussion was to run all extensions through an automated test that checked for the blocked, gray-area behaviors, then to sign those extensions that pass using a key that only Mozilla holds. Firefox has long supported signed extensions, but the feature has rarely been used by developers. Mozilla will add a compile-time switch that makes Firefox to check for the Mozilla signature on every extension. Extensions that do not pass the signature check will be deactivated. Future Firefox releases will then be built with the signature-checking switch enabled.

That part of the plan is relatively straightforward; where things get more complicated is how the extension-signing process will be implemented. First, there will be new steps required for developers whose extensions are not hosted at Mozilla's official add-on site, addons.mozilla.org (AMO). Since AMO-hosted extensions are already required to pass a review step, the good-behavior test and signature will simply be rolled into that same process. But developers who provide extensions on their own site will have to create an AMO account and submit each build for the test-and-signature process.

The extension IDs used by each account will be logged, so that Mozilla can note suspicious behavior (like submitting a different user's extension ID, or submitting thousands of IDs). These third-party developers' AMO accounts and extensions will never be visible to the public, though, and they can continue to distribute their code at their own sites. Villalobos also mentioned that there will be yet a third process for use by developers who create extensions designed only to be used on an internal (e.g., enterprise) network—but the nature of that internal-extension-development process has yet to be announced.

The second issue is that not all well-behaved extensions will pass an automated test. But the precise nature of the automated test has not yet been made public. Villalobos said that any extension that fails can be submitted for a manual review, which Mozilla hopes will take at most a couple of days. Furthermore, he expressed Mozilla's willingness to work with known extension developers who have special needs on a case-by-case basis. The vast majority of extensions are expected to pass the automated test, since very few of them have any reason to use the functionality exploited by the problematic gray-area extensions.

Finally, although the plan hinges on not providing a run-time switch to disable signature checking (because any run-time preference or switch could be exploited by a malicious extension or installer), Mozilla will release the Developer Edition and Nightly builds of Firefox with signature-checking turned off, so that developers can test their code without waiting on signatures. Mozilla will also provide special "unbranded" Firefox builds with signature-checking disabled, via a separate download site. The unbranded builds are something of a last resort: extension developers can point users toward those builds if they cannot or will not get their extensions signed.

The signature-checking system will be rolled out in a transitional state for two full Firefox release cycles (i.e., 12 weeks), perhaps beginning as soon as Firefox 39 (currently scheduled for late June). During the transition phase, extensions that fail the signature check will prompt a warning, but will continue to run. As of now, no other add-on types (such as themes, dictionaries, plug-ins, or search engines) will be signature-checked, and there are no plans to roll out signature checking for Thunderbird or for Seamonkey (although either of those projects could independently decide to deploy the same scheme).

Feedback

As might be expected, the announcement drew plenty of vitriolic criticism; quite a few commenters on the blog post accused Mozilla of "Apple-like" or "Google-like" behavior by exerting central control over extension distribution, for example. Others likened the plan to censorship, arguing (for instance) that once the process was in place, the US government or the entertainment industry would begin pressuring Mozilla not to sign extensions they disliked. The debate was also carried over to the mozilla.addons.user-experience discussion group, where the deliberations certainly had their own share of name-calling—although participants in that forum focused primarily on how the new system would impact the process of developing extensions.

In both discussions, however, some common questions recurred. Several asked why the signature-checking scheme relied only on a signing key from Mozilla—as opposed to, say, per-developer keys, or reusing some existing trust mechanism. Villalobos replied that per-developer keys are too easily compromised by malicious developers. Similarly, Adam Novak argued that trying to implement similar safeguards through the SSL Certificate Authority (CA) system would also be easily undermined by malware developers.

Since Mozilla is intent on being the only entity that can sign an extension as passing the good-behavior test, others complained about the fact that there will be no run-time mechanism to disable signature checking. At his blog, Jeff Lyon called the plan a violation of the core principles in the Mozilla manifesto and of the spirit of free software. Subsequently, he posted his own alternative proposal to the discussion forum, in which users would be able to switch off signature-checking by visiting a Mozilla-hosted site that would generate a cryptographic token (signed by Mozilla) for each user. The token, he said, would ensure that the user had expressed their consent to switch off signature-checking, and it could be hidden behind a CAPTCHA-like "human test" to prevent abuse by malware authors.

But Lyon's suggestion, like the other run-time switch proposals, was rejected. Essentially, the Mozilla team argued, there is no run-time mechanism that cannot be exploited: CAPTCHAs are easily broken, web page interaction can be scripted and run without the user's knowledge, and settings can be altered. Mike Connor replied that there is no way to allow unsigned non-malware extensions to run that would not be exploited. "It's unlocking a door to let in a friend, then leaving it unlocked forever." In addition, he said, the goal is to dramatically reduce the amount of gray-area malware in the wild, as a "herd immunity" goal.

Forward progress

Ultimately, most of the extension developers' concerns boil down to the fact that they like to push out test builds for their extension's users—sometimes even making a special build to be sent directly to a single bug reporter. Villalobos and the other Mozilla employees continued to insist that the automated extension test would not introduce a significant slow-down to that process. But it seems like many extension developers find that hard to believe.

Perhaps it would be easier to make that case if there were more details available. After all, it is easy for skeptics to imagine that the extension-checking process will be slow and work poorly when there is no evidence to the contrary. That puts Mozilla in an unenviable position, to be sure.

Similarly, there is a lot of confusion about some parts of the plan that have yet to be rolled out—such as the "unbranded" Firefox builds that will have signature-checking disabled. As Villalobos described it, users will have to seek out the unbranded Firefox builds and install them intentionally (perhaps through the Mozilla Developer Network, rather than the usual download site). Once installed, the lack of "Firefox" branding should make it obvious that a different browser is in use, so it will be hard for a malware author to trick a user into installing the vulnerable build. But that, too, is a mechanism that it is all too easy to imagine not working as expected. Mozilla will still have to show it functioning in the wild to win over some developers.

It is also unclear how the signature scheme will affect Linux distributions. Some might be interested in making Firefox builds available that have the signature-checking code compiled out. Whether or not that change would be enough to trigger a trademark dispute of the sort that led Debian to rebrand its Firefox builds as "Iceweasel" has not been explored.

In the meantime, Connor reminded those in the thread that the real goal was to improve users' security:

Villalobos, too, pointed out that the problem Mozilla is attempting to solve is that the status quo offers essentially no mechanism to block bad actors:

Connor also took issue with the suggestion that the plan violates free-software principles, noting that anyone who objects to it can still install one of the Nightly or Developer Edition builds—or even recompile Firefox themselves.

Tyler Downer estimated that the number of gray-area Firefox extensions in the wild was in the millions. That is surely a problem that needs to be addressed. How onerous extension developers and users ultimately find the new signature-checking scheme remains to be seen. It may make a significant dent in this long-standing problem—although it will surely not be the end of the Firefox malware story.

Comments (23 posted)

Security quotes of the week

Comments (36 posted)

deb.haskell.org compromised

Comments (27 posted)

FreeBSD random number generator broken for last 4 months

Comments (28 posted)

chromium: multiple vulnerabilities

Comments (none posted)

clamav: multiple vulnerabilities

Comments (none posted)

cpio: directory traversal

Comments (none posted)

cups: buffer overflow

Comments (none posted)

dbus: denial of service

Comments (none posted)

file: memory leak

Comments (none posted)

glibc: two vulnerabilities

Comments (none posted)

jython: code execution

# (umask 000; jython -c 'import xmllib')
# ls -l '/usr/share/jython/Lib/xmllib$py.class'
-rw-rw-rw-. 1 root root 52874 Apr  3 17:24 /usr/share/jython/Lib/xmllib$py.class

Comments (none posted)

kernel: multiple vulnerabilities

Comments (none posted)

mdadm: command injection

Comments (none posted)

moodle: cross-site scripting

Comments (none posted)

oracle-jre-bin: multiple unspecified vulnerabilities

Comments (none posted)

perl-Gtk2: code execution

Comments (none posted)

php5: multiple vulnerabilities

Comments (none posted)

pigz: directory traversal

Comments (none posted)

puppetlabs-stdlib: privilege escalation

Comments (none posted)

roundcubemail: cross-site scripting

Comments (none posted)

sudo: information disclosure

Comments (none posted)

unzip: code execution

Comments (none posted)

virt-who: information leak

Comments (none posted)

xorg-server: information leak/denial of service

Comments (none posted)