Extension Manager:Addon Update Security

Please don't edit this page directly, either add comments to the discussion page or to the threads in the newsgroup or forums. See also the original newsgroup thread where extension authors discuss the potential impact to the addon community.

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. In particular, neither url is required to be https. This allows either the update manifest or the update package to be compromised, potentially resulting in the injection of malicious updates. 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.

Each can be achieved in two different ways giving a total of 4 different methods available to add-on authors for securing the update process.

Ensuring Update Manifest Security

In order to ensure that the update manifest is retrieved securely add-ons must use one of the following two methods of securing the manifest:

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. Any failure here will be logged through the extension manager for add-on authors to see.

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

To be clear, the key used for these signatures is not required to be one purchased from a trusted CA, it can be a self-signed key. In the SSL case, a trusted CA is a necessary intermediary to establish domain ownership and prevent man-in-the-middle attacks. In this case, however, we can verify the authenticity of the update signing key by comparing it with the one stored in the initial install, a trusted intermediary is not required.

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

Further details of the signing are available at Extension Manager:Addon Update Security:Signature

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. The failure will appear to the user as a general error with the update manifest. Add-on authors will be able to get more detailed information by enabling the extension manager logging.

Ensuring Update Package Security

In order to ensure that the update package is retrieved securely one of the following two methods must be used:

Securing Update Packages Through SSL

Delivering the xpi package over an SSL is the simplest way to ensure that it reaches the user untampered with.

Securing Update Packages Through Hashes

If the update package is not being delivered by an SSL connection then an updateHash entry must be present. This is a hash calculated from the xpi file and will currently be limited to the sha1, sha256, sha384 and sha512 algorithms.

Even when using an ssl connection the updateHash may be used for added confidence that the file retrieved is the correct one, however this protects the user from a mistake by the add-on author rather than from any malicious intent.

Covering Compromises

Both of the methods for securing update manifests require that the add-on author keep their signing key or ssl private key secure. The ssl method also requires that the add-on author continues to be the owner of the domain name the manifest is hosted from.

In the event that the author loses the domain the ssl site is hosted from or they believe that their ssl certificate or signing key have become compromised then they should notify Mozilla immediately so that appropriate steps can be taken.

Non-conforming Add-ons

Add-ons that include a custom update URL and 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. Add-ons that do not provide updates and so do not include and update URL, and add-ons that use the default URL for update from AMO will be allowed to install as normal.

When Firefox refuses to install such add-ons the error message will likely be very simple, quite probably the standard incompatible message. However extra information about the reasons for the installation failure will be logged from the extension manager in the usual way.

Migration

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

When the user updates all add-ons that do not support secure updates will be disabled (they should not be marked as compatible with Firefox 3 in any case). However Firefox will continue to check for updates to the extension normally. It will only install updates that meet the new criteria for extension installs, that is the update add-on must support secure updates.

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