Firefox3.1/Blocklisting Security Review

From MozillaWiki
Jump to: navigation, search

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

Security and Privacy

  • What security issues do you address in your project?

The blocklist data is downloaded over https. The service is implemented in JavaScript so should not suffer from memory related bugs.

Need to verify how the blocklist service behaves with bad ssl certs

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

nsIBlocklistService

https://bugzilla.mozilla.org/attachment.cgi?id=345401

https://bugzilla.mozilla.org/attachment.cgi?id=345404

https://bugzilla.mozilla.org/attachment.cgi?id=345405

https://bugzilla.mozilla.org/attachment.cgi?id=345406

  • Does it interoperate with a web service? How will it do so?

The blocklist is retrieved using a single https request once a day. Information about the application is encoded into the url of the request so that the blocklist can be tailored for the application as necessary. The url used is currently: 

https://addons.mozilla.org/blocklist/3/%APP_ID%/%APP_VERSION%/%PRODUCT%/%BUILD_ID%/%BUILD_TARGET%/%LOCALE%/%CHANNEL%/%OS_VERSION%/%DISTRIBUTION%/%DISTRIBUTION_VERSION%/
  • Explain the significant file formats, names, syntax, and semantics.

The downloaded blocklist is an XML file. Its syntax is described elsewhere. Very roughly for extensions it contains ID, version and target applications where they should be blocked. For plugins it contains regular expressions to match against the plugin metadata and version and target application information. Both extension and plugin blocks may contain a severity that allows the block to be changed to only warn the user.

  • Are the externally visible interfaces documented clearly enough for a non-Mozilla developer to use them successfully?

The IDL documentation is all that exists though it is fairly self explanatory. It is not really expected that non-Mozilla developers would be using this interface though.

  • Does it change any existing interfaces?

The new severity feature required additive changes to the interfaces

Module interactions

  • What other modules are used (REQUIRES in the makefile, interfaces)
    • IO
    • Network
    • Preferences
    • DOM parsing
    • Version comparator
    • Plugin host
    • Extension manager

Data

  • What data is read or parsed by this feature

Only the blocklist xml file is parsed. The service relies on the extension manager and plugin host to provide details about the installed add-ons.

  • What is the output of this feature

The service can be queried to see if a particular add-on is blocked and periodically blocks/unblocks add-ons as a new blocklist is downloaded.

  • What storage formats are used

The blocklist is held as an xml file in the profile folder. There is also a copy of the blocklist shipped with the application for use when a different version has yet to be downloaded to the profile.

Reliability

  • What failure modes or decision points are presented to the user?

Any failure to download or parse the blocklist is hidden from the user. The only decision point is when a user attempts to install an add-on that is soft blocked, at that point they will be asked if they really want to install it.

  • Can its files be corrupted by failures? Does it clean up any locks/files after crashes?

The service is reliant on AMO providing a correct blocklist XML file. If AMO responds with an error status or with something that isn't XML then the blocklist service will ignore it. If it was possible for AMO to return something that is valid XML but doesn't contain correct blocklist data then the blocklist service would simply act as if nothing were blocked.

Configuration

  • Can the end user configure settings, via a UI or about:config? Hidden prefs? Environment variables?

Users can change blocklist settings in about:config. It is possible for them to completely turn off the blocklist there if they choose to do so, it is also possible to adjust the threshold at which a soft block becomes a hard block.

  • Are there build options for developers? [#ifdefs, ac_add_options, etc.]

None

  • What ranges for the tunable are appropriate? How are they determined?

extensions.blocklist.interval determines how often the blocklist is refreshed. It is currently set to one day. bug 465570 has some discussion on changing the default.

extensions.blocklist.level determines the severity that is a hard block. It can be adjusted between 0 and 3 and Firefox 3.1 has it defaulting to 2.

  • What are its on-going maintenance requirements (e.g. Web links, perishable data files)?

AMO has a database that is changed as new items are blocked and items are unblocked.

Relationships to other projects

  • Are there related projects in the community?

As far as I am aware no other application developer maintains their own blocklist so the changes should not impact anyway. However the changes have been made in a backwards compatible fashion. A blocklist of the format that Firefox 3.0 understood will still work and have the same effect in Firefox 3.1.

Review comments

  • Need to check that a bad certificate error when retrieving the blocklist is handled correctly
  • What do we do if attempts to update the blocklist fail consistently for a long time, the user has no current blocklist
  • Change text to point out that only a particular version is blocked, something like "Minefield has determined that the following versions of add-on are known to cause stability or security problem, you might want to check for updates." bug 468524
  • Perhaps the blocklist more information url should be https bug 468526
  • We should be escaping the parameters in the blocklist url bug 468527
  • Perhaps we could speed up blocklist requests in the event of an error
  • Should we log blocklist request failures to some console as at least an indication there is a problem
  • Check what happens if the plugin regular expression is malformed, try to restrict one typo from breaking the entire blocklist bug 468528
  • Does the update check any If-Modified-Since header
  • Should clicking check for updates in the add-ons manager do a blocklist update check as well? This could warn about blocklist update failures more explicitly
Retrieved from "https://wiki.mozilla.org/index.php?title=Firefox3.1/Blocklisting_Security_Review&oldid=119949"