Extension Manager:Addon Update Security

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. It will be noted later that this feature does have an impact on the install process however.

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.

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.

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

• bug 378216 - Overall bug tracking this feature.