Firefox3.1/Blocklisting Security Review

Overview

The work on the add-ons blocklist for Firefox 3.1 has been a series of incremental to improve both the capabilities of the blocklist and the user notification of blocklist events.

Primarily we have added support for severities to the blocklist. A version of an add-on will be included in the blocklist at a specific severity level. Firefox will behave differently depending on whether this severity is above or below a certain threshold. If the severity is too high then the add-on will be totally blocked in the same way as in previous versions of Firefox. If the severity is lower then the add-on may still be used however the user will be warned that the add-on may cause problems.

The second main goal was to improve notification to the user about when plugins are blocklisted. This has been tackled in two ways. Firstly when a new blocklist is downloaded and new add-ons blocked because of it we display a dialog listing all the effected add-ons (previously we only listed extensions): https://bugzilla.mozilla.org/attachment.cgi?id=345404. Secondly when the user visits a webpage that attempts to use a blocked plugin we now include an in-page box where the plugin would be. The same is now true for disabled plugins and the user can click the box to get the add-ons manager open in order to manage their plugins.

Background links

• https://wiki.mozilla.org/User:Mconnor/PluginBlocklisting
• bug 455906 Support severities for blocklist entries
• bug 449027 Support specifying application range for plugins in blocklist.xml

• bug 391714 Notify user when plugin is blocklisted
• bug 391728 No placeholder for disabled plugins
• bug 427743 Expose File Version Number of Plugins

Security and Privacy

• What security issues do you address in your project?

The blocklist itself is a way to mitigate security issues in third-party add-ons to the application.

The blocklist itself is downloaded over https. The service is implemented in JavaScript so should not suffer from memory related bugs. Once blocked the add-ons are no longer meant to be loaded at all.

• • Need to verify how the blocklist service behaves with bad ssl certs
  • There is a problem with plugins on non-windows OS where the shared library must be loaded into memory to query the plugin metadata that will tell us if the plugin should be blocked or not.

• Is system or subsystem security compromised in any way if your project's configuration files / prefs are corrupt or missing?

The application ships with a default blocklist file however the absence of any blocklist file would not cause any problems. Any preferences have values set in the application defaults.

• Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project.

• • I believe it may be possible for webpages to detect whether plugins have been blocklisted or disabled using a similar method to the history detection trick. I'm not sure whether this constitutes a real risk at all.

• How are transitions in/out of Private Browsing mode handled?

The blocklist is not watching for transitions to and from private browsing mode. While the service does download a new blocklist once a day I don't believe we should not do that when in private browsing mode. It does not reveal anything about what the user was doing at the time.

Exported APIs

• Please provide a table of exported interfaces (APIs, ABIs, protocols, UI, etc.)
• Does it interoperate with a web service? How will it do so?
• Explain the significant file formats, names, syntax, and semantics.
• Are the externally visible interfaces documented clearly enough for a non-Mozilla developer to use them successfully?
• Does it change any existing interfaces?

Module interactions

• What other modules are used (REQUIRES in the makefile, interfaces)

Data

• What data is read or parsed by this feature
• What is the output of this feature
• What storage formats are used

Reliability

• What failure modes or decision points are presented to the user?
• Can its files be corrupted by failures? Does it clean up any locks/files after crashes?

Configuration

• Can the end user configure settings, via a UI or about:config? Hidden prefs? Environment variables?
• Are there build options for developers? [#ifdefs, ac_add_options, etc.]
• What ranges for the tunable are appropriate? How are they determined?
• What are its on-going maintenance requirements (e.g. Web links, perishable data files)?

Relationships to other projects

Are there related projects in the community?

• If so, what is the proposal's relationship to their work? Do you depend on others' work, or vice-versa?
• Are you updating, copying or changing functional areas maintained by other groups? How are you coordinating and communicating with them? Do they "approve" of what you propose?