Security/Reviews/Firefox4/about:addons Security Review

From MozillaWiki
Jump to: navigation, search

Security Review

Overview

For Firefox 4 we have completely replaced the code that handles downloading, installing and updating extensions, themes and locale packs. We've also replaced the UI that manages all add-ons in the add-ons manager. There were a number of goals for the work:

  • Clean separation between backend and UI allowing applications to easily replace the UI with their own if they wish
  • Implement a type of extension that can be installed without restarting
  • Remove the under-utilised extension dependency support
  • Stop extracting extensions and instead leave them as a single XPI file in the profile where possible
  • General refactoring to make the startup code less fragile and capable of handling corrupt databases
  • Replacing the C++ xpinstall implementation which handles webpages triggered installs, downloading and certificate verification with something that is JS based
  • Creating a standard API that the application an extensions can use to access information about add-ons (previously direct access to the RDF database was required and plugins were accessed in a different way entirely)
  • Switching from an RDF database to SQLite
  • Periodically download additional metadata from AMO for all installed add-ons
  • Display the add-ons manager UI in a tab rather than a new window
  • Add a pane to display content from AMO in the new add-ons manager
Background links

Threats

Please list the top 3 security threats you have considered during the design and implementation of this feature. Consider attack points as well as code that feels fragile.

  • Ensuring that installing and updating extensions remains as secure as previously
  • Making sure that only AMO content can display in the add-ons manager
  • Blocklisting restartless add-ons requires calling code in the add-on to shut it down

What mitigations have you implemented?

  • Improved our test suite for security issues when downloading/updating and also made the code slightly stricter about only allowing a https->http redirect when a hash has been provided
  • Added a means for a hash to be provided when transferring from https->http to allow non-JavaScript initiated installs to remain secure even when using insecure mirrors
  • About to land code that verifies that the AMO content is always from SSL and the AMO domain.

Topics To Discuss During The Review

Security

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

  • This is not a security feature however introducing extensions into the product can expose risks to the end user.
    • The only change from Firefox 3.6 is the introduction of restartless extensions. We call JS code in these extensions whenever they are enabled ro disabled. The extension is expected to fully remove itself from the application when asked to do so. We have no means to ensure that this actually happens currently.
  • Is system or subsystem security compromised in any way if your project's configuration files / prefs are corrupt or missing?
    • All state files can be regenerated and even if the files cannot be saved then Firefox will continue to operate mostly normally

Privacy

  • Does the feature expose information that could strengthen fingerprinting?
    • Daily add-on update checks are made, the majority to AMO (This is the same as in 3.6)
    • Daily GUID pings are made to AMO to retrieve additional add-on metadata, all in a single HTTP request.
  • Does the feature cache or store data that could strengthen super-cookies?
    • No
  • How are transitions in/out of Private Browsing mode handled?
    • N/A (How individual extensions handle private browsing mode is up to them)
  • How is "Clear Recent History" handled?
    • N/A

Data

  • What data is read or parsed by this feature?
    • We read RDF files from installed extensions and from update checks. We verify data types when necessary.
    • We read XML files from the AMO API for searching and metadata retrieval. We verify data types when necessary.
  • What is the output of this feature?
    • The JSON encoder and SQLite APIs are used for writing all data which takes care of encoding for us.
  • What storage formats are used?
    • A cache of metadata for installed add-ons is held in a SQLite database in the profile folder. There is no private data held.

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?
    • Corrupt files should not happen in the normal course but we regenerate corrupt files losing very little data

Configuration

  • Can the end user configure settings (via UI, about:config, or environment variables)?
    • Automatic update settings exist in the UI and then some settings like update frequency appear in about:config
  • Are there build options for developers (e.g. #ifdefs, ac_add_options)
    • No
  • What are its on-going maintenance requirements (e.g. Web links, perishable data files)?
    • AMO is required to provide the API we support to retrieve metadata for installed add-ons

C and C++

  • No C++ code is used

Exported APIs

Please provide a table of exported interfaces (APIs, ABIs, protocols, UI, etc). Explain the significant file formats, names, syntax, and semantics.

  • Does it interoperate with a web service?
    • The AMO API and update services are accessed over HTTPS
  • Are the externally visible interfaces documented clearly enough for a non-Mozilla developer to use them successfully?
    • We have documentation on the update service on MDN and a limited amount of documentation on the AMO API on wikimo
  • Does it change any existing interfaces?
    • Yes

Module/Library interactions

  • No binary modules required beyond libxul

Relationships to other projects

  • Other developer maintain their own add-on update systems, we notify them of changes through various blogs and newsgroups when necessary.

Review comments

Notes and bug numbers will be recorded here. Let's try not to spend too much time on any one topic during the meeting.

Retrieved from "https://wiki.mozilla.org/index.php?title=Security/Reviews/Firefox4/about:addons_Security_Review&oldid=273841"