Extension Manager:Addon Update Security

From MozillaWiki
Revision as of 17:49, 29 June 2007 by Johnath (talk | contribs) (Rephrasing to make it clearer (to me :) that this will still touch install experience.)
Jump to navigation Jump to search

Overview

This specification discusses changes to the Toolkit Extension Manager in Gecko 1.9 with the aim of improving the security of automated add-on updates.

Scope

It should be stressed that this feature is targeted at ensuring the security of updates to add-ons and has no impact on the security of initial add-on installs. Nevertheless, as noted below, this feature will have an important impact on the initial install process.

The restrictions on installs and updates that this feature includes will be applied to all add-on types.

Terms

Install manifest
The add-on metadata held in the install.rdf file inside the add-on's xpi.
Update manifest
The update metadata delivered from a website using the rdf format (update.rdf).
Update package
An updated version of the add-on in xpi form.

Many points in the specification mention Firefox 3 however the actual application is irrelevant and the same will apply for any application based on Gecko 1.9 using the Toolkit Extension Manager.

Current Situation

Firefox currently automatically checks for updates to add-ons using a url specified in the add-on's install manifest. The file retrieved from this url must be an update manifest. This in turn contains urls for update packages for the add-on.

Currently there are no requirements placed on these urls. They can both be insecure http which allows methods of compromising either the update manifest or the update package. A demonstration of one form of compromise is already public.

Proposed Implementation

In order to make the automatic update of add-ons secure there are two main steps to be taken:

  • Ensure that the update manifest is retrieved in a secure fashion
  • Ensure that the update package retrieved matches that specified by the update manifest.

The following details how we meet those steps.

Requiring Update Hashes

The update manifest currently contains an optional property, the updateHash. This will become an absolute requirement for updates. Any updates listed in the update manifest missing a hash will be ignored.

  • Do we need to restrict the hashes available? Currently we allow md2, md5, sha1, sha256, sha384 and sha512. Presumably finding a collision that still makes a valid add-on in an xpi file will be quite a challenge.

This provides a high level of confidence that the update package that will be downloaded is the same update package referenced from the update manifest regardless of the security of the connection used to retrieve the package.

Securing Update Manifests Through SSL

Add-ons may choose to host their update manifest on a secure site backed by a valid SSL certificate. This is likely to be the easiest case from a developers point of view and probably the only method suitable for automatically generated update manifests such as those being built from a database.

This mechanism ensures that the update manifest has been retrieved un-tampered from the url specified by the add-on. It should be noted though that this does not guarantee the update manifest came from the original add-on author since the domain name hosting the manifest may have changed hands.

Note that it is not enough for the update url to be specified as https, a check will be made that the certificate is valid and that the url at no point redirects to a non-secure url.

Securing Update Manifests Through Digital Signatures

Add-ons authors may instead choose to sign the update manifest with a digital signature. In order to accomplish this they must generate a public and private key pair. They will keep the private key secret and include the public key in the add-on (actual place tbd but likely as an extra file or resource in the install.rdf).

The private key is then used to sign the contents of the update manifest an an additional property of the update manifest will contain the signature.

  • Need to provide tools to make this simple, possibly an xulrunner app.

During an update check the public key in the already installed add-on will be used to verify the digital signature against the update manifest's content ensuring that it has not been tampered with.

If the digital signature suggests that the update manifest has been tampered with then the entire update manifest is ignored and the update check is taken to have failed. It should be noted that this will occur even if the update manifest was delivered over an SSL connection.

  • What do we do if we have no public key and the update manifest has a signature and it was delivered over SSL?
  • What do we do if we have a public key and the update manifest has no signature but it was delivered over SSL
  • Need to spec out precisely what the signature is signing.

Non-conforming Add-ons

Add-ons that do not provide either of the previous methods of retrieving a secure update manifest must not mark themselves as compatible with Firefox 3. During install a check will be performed to ensure that it meets the requirements and Firefox will refuse to install any add-ons that do not.

  • How stringent do we be? Likely we cannot verify that the public key is valid without performing an update check there and then

Migration

In order to support updating add-ons which do not currently meet the new requirements there will be the possibility of a single insecure update check for the add-on when the user first updates to Firefox 3.

In this case a standard insecure update check can be performed. If the check finds an update marked compatible with Firefox 3 then the user may opt to install it. The update package will then undergo the same checks as during a regular install in Firefox 3 and assuming it succeeds (which is should if it is marked as compatible with Firefox 3) then the add-on will be updated and receive secure automatic updates thereafter.

Impact to Add-on Authors

Authors Currently Hosting at AMO

Authors that host their add-ons at AMO should see no impact from this feature.

Authors Currently Hosting Updates Manifests from SSL Websites

Any authors that host their add-on's update manifest from an SSL enabled website will only need to ensure that their update manifest contains update hashes for each update listed.

Other Authors

Any other add-on authors have two options open to them. Either they can switch to secure hosting through SSL, or they will have to begin using digital signatures to sign the update manifest. In either case in order to continue to deliver automatic updates to their users after Firefox 3 is released they must release a new version of their add-on supporting Firefox 3 before their users update to Firefox 3. See the Migration section for more details.

Related Bugs

Retrieved from "https://wiki.allizom.org/index.php?title=Extension_Manager:Addon_Update_Security&oldid=60926"