Extension Blocklisting

Please comment in the Talk page (use the Discussion tab above)

Tracked by: bug 318338

Goals & Objectives

The primary objectives of this project are to:

• Provide a method to remotely disable extensions due to
  • security vulnerabilities
  • behaviors that adversely impacts the user experience (e.g. application incompatibility even when it claims compatibility, memory leaks, etc.)
  • unforeseen behaviors (e.g. causing a denial of service for a site, etc.)

Planned Milestones

Alpha 1	Extension Manager	code complete
	User Interface	operational (needs tuning)
Alpha 2	Blocklist File	hosted / owned on A.M.O.
	Blocklist Details page	hosted / owned on mozilla.com
	User Interface	code complete

Overview

Firefox runs both extensions and plugins at elevated privilege, opening users up to attack vectors left open either intentionally (a malicious extension/plugin which may have been installed by some trickery) or unintentionally.

Once an exploit is known to the community, it should be our responsibility to take measures to protect our installed users from these attack vectors. To do so, a "blocklist" will be kept which will be an always up-to-date list of plugin and extension versions that have been found to be vulnerable to attack. A local copy of this list will be updated using the Software Update mechanism. If an installed plugin or extension matches this list, it will be disabled and the user will be informed.

Use Cases

The following has been identified as the potential use cases for extension blocklisting:

• extensions that break the application
• extensions that have security vulnerabilities
• extensions that crash the application
• extensions that advertise a targetApplication for a future release that break the future release
• extensions that have memory leaks that adversely affect the performance of the application
• malicious extensions that have an identifiable id (e.g. an id that doesn't change)

Several of these terms are purposefully subjective and will be defined as the process for managing the blocklist is developed.

Functional Requirements

• The blocklist url will be defined on a per application basis (e.g. blocklisting will be controlled by the application distribution)
• Inform users when a blocklisted item has been detected
  • tell users what this means
  • provides a link to more information
  • disable the item
• Provide some level of control over whether the blocklist is enabled
  • probably not first-level UI for this (about:config prefs)
• Some way of indicating that an installed extension is disabled because it has been blocklisted
  • should still allow a user to check for updates
• Every application should have its own blocklist (e.g. unique blocklist url)
  • an extension could be insecure with one application and secure with another application
• It should be possible to specify an application version range that an extension is insecure with.
  • it is possible that an update to the application can make an extension secure and we still need it to be blocklisted for other versions of the application

Plans & Design Documents

• User Interface Design
• Code Design
• Test Plan
• Documentation Plan

API Changes Required

No API changes. nsIExtensionManager::getIncompatibleItemList will not return items that are blocklisted. Since a new method will need to be created for bug 324121 this will be handled in that bug.

Impact

The current design impacts the following areas of development ...

Extensions

• No impact. Information regarding the process for adding an extension should be documented including what qualifies an extension to be blocklisted and this should be provided to the extension author community.

Localization

• Additional strings will be required

Update

• No impact. Changes to incorporate blocklisting into the app update extension incompatibility warning will be taken care of in bug 324121.

Discussion & Implications

Caveats / What We've Tried Before

N/A

Security Implications

The blocklist is not a front line defense against malicious extensions and is not in scope for this implementation since once an extension is installed it would be able to disable the blocklist. Methods for making it more difficult to disable the blocklist from an extension will be considered and implemented when it makes sense to do so.

Privacy Considerations

N/A - no information will be sent to any site due to this project except possibly application ID as we do for application and extension update checks.