999014 - Allow AMO addons to sign updates

Status: RESOLVED WONTFIX

(addons.mozilla.org :: Security, defect)

Description

[yan]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:28.0) Gecko/20100101 Firefox/28.0 (Beta/Release)
Build ID: 20140314220517

Steps to reproduce:

I'm the maintainer of EFF/Tor's HTTPS Everywhere addon. Currently we self-host the addon itself and update.rdf: https://www.eff.org/files/https-everywhere-update-2048.rdf. For security reasons, update.rdf includes the xpi file hash and is signed by an offline signing key that lives on a dedicated airgapped machine. (In addition, everything is served over HTTPS.)

Many users have asked us to put HTTPS Everywhere in AMO, but AMO does not let us specify an updateKey and updateUrl in install.rdf. From reading past bugzilla threads, I understand that this stems from the belief that users are more protected from update hijacking if AMO addons don't specify their own update URLs. But HTTPS Everywhere actually has *more protection* against update hijacking than AMO addons, because of our offline code signing process.

From talking to Mozilla security folks, I gathered that AMO addons have no code signing process at all. So if AMO's SSL private key were compromised (such as by Heartbleed), an attacker would be able to push malicious updates to most AMO addons. I would like HTTPS Everywhere to continue to be protected from this scenario.

(BTW, I realize that AMO addons can be signed via this process: https://developer.mozilla.org/en-US/docs/Signing_a_XPI. However, it would take some work for that process to be compatible an airgapped private key, and furthermore, I am not comfortable relying on CA-signed certs until public key pinning lands in Firefox.)



Expected results:

AMO should allow add-ons to specify an updateUrl and updateKey. Perhaps it would even be fine to require that AMO host the update.rdf file for AMO addons. I don't think there is any reason for an add-on to have an updateUrl without an updateKey, FWIW.

Comment 1

[Kris Maglione [:kmag]]

We don't allow AMO add-ons to serve updates from off-AMO. This is by design. If you want to host your add-on on AMO, all updates need to be served from AMO.

In any case, update signing is unrelated to code signing.

Comment 2

[yan]

That's fine, but can AMO let us sign AMO-hosted updates with our own key?

Comment 3

[Kris Maglione [:kmag]]

No. There are too many reasons not to do that and too few benefits. We don't require update.rdf files to be signed when they're served over HTTPS, since HTTPS provides the same level of verification as an updateKey, and we don't see significant benefit to the additional level of verification. It would also add significant technical complexity, require us to store your private key, provide different levels of security for different add-ons we host (and not a significant one, since the universal hotfix add-on does not have that level of signing and could be used to replace your add-on)

Comment 4

[Bryan Quigley]

>since the universal hotfix add-on does not have that level of signing and could be used to replace your add-on
So should it get that?  It seems to me that signing this would provide more protection than just depending on SSL alone.  When Firefox does an update does it just trust HTTPS or does it verify the update?

A related post: http://blog.dustinkirkland.com/2014/05/double-encryption-for-win.html

Comment 5

[Eldon Koyle]

Trusting SSL is great and all until one of the widely-used CA keys is compromised or openssl has another embarrasingly severe exploit.  Maybe it is worth adding that level of signing to everything?  A malicious update is a terrifying prospect.

If you consider SSL to be the end-all and be-all of security, please go look through your browsers trusted certificate list and ask the following question for each entry:  "Could (or has) the government of this country demand(ed) the private key from this CA?"

Comment 6

[Daniel Veditz [:dveditz]]

Changing this to WONTFIX: it's certainly a reasonable request in isolation, that we're not prepared to allow on AMO given the scale. INVALID doesn't quite convey that.

> From reading past bugzilla threads, I understand that this stems from the
> belief that users are more protected from update hijacking if AMO addons
> don't specify their own update URLs. But HTTPS Everywhere actually has
> *more protection* against update hijacking than AMO addons, because of
> our offline code signing process.

The "hijacking" we worry about is from the addon authors themselves: we review and OK a benign add-on and then it self-updates into malware or adware. This is not a hypothetical worry. The EFF isn't going to do that, obviously, but the number of entities we trust to that extent who cannot simply host on AMO is so small that we can't spare the coding resources to create an exception mechanism.

(In reply to Eldon Koyle from comment #5)
> please go look through your browsers trusted certificate list and ask the
> following question for each entry:  "Could (or has) the government of this
> country demand(ed) the private key from this CA?"

Also a legitimate worry which is why addons.mozilla.org certs (and other Mozilla sites) are pinned in Firefox.

Comment 7

[Jesse Ruderman]

Could you allow the extension to say "updates must be signed by both Mozilla and EFF"? Then you don't have to make an exception to the "updates must be signed by Mozilla" rule, and EFF's addons can have the additional security that comes from their separate airgapped infrastructure.

Comment 8

[yan]

(In reply to Jesse Ruderman from comment #7)
> Could you allow the extension to say "updates must be signed by both Mozilla
> and EFF"? Then you don't have to make an exception to the "updates must be
> signed by Mozilla" rule, and EFF's addons can have the additional security
> that comes from their separate airgapped infrastructure.

That would fulfill my use case.

Comment 9

[Alexander E. Fischer]

(In reply to Jesse Ruderman from comment #7)
> Could you allow the extension to say "updates must be signed by both Mozilla
> and EFF"? Then you don't have to make an exception to the "updates must be
> signed by Mozilla" rule, and EFF's addons can have the additional security
> that comes from their separate airgapped infrastructure.

It would be great if this could be reconsidered. Please allow end-to-end authentication between the developer and the user to happen.

Comment 10

[Mike Connor [:mconnor]]

So in a world where AMO does all code signing, and we're using pinned certs for getting update information from AMO, what's the specific user use-case that we'd address through somehow preserving an additional signature?  The current XPI signing model doesn't really support multiple signatures, so that's the primary technical limitation here.  That's a pretty big wheel to reinvent, so I'd really like to understand what this would accomplish in the new model.

Comment 11

[Kumar McMillan [:kumar]]

I think this issue can be resolved. Yan, could you confirm? 

I just attempted to submit an unlisted add-on to AMO with an updateKey and updateURL in the manifest and it was accepted and signed. That means one could use our automated tools (in the works) to Mozilla-sign an XPI file that auto-updates at a custom URL. Would that address the problem? The work flow would be like this:

* develop add-on
* include updateURL and updateKey
* auto-sign the XPI (jpm sign will do this: https://github.com/mozilla-jetpack/jpm/issues/327)
* on an air-gapped machine, add your own signature to the XPI file as the JAR signing spec allows (or perhaps you meant the updateKey would include this custom signature?)
* host the signed add-on XPI on your own server (not on AMO)
* Firefox will install this add-on because the XPI will include Mozilla's signature

Comment 12

[Kris Maglione [:kmag]]

I don't know why this was reopened. This is about allowing developers to sign the update manifests served by AMO, not about unlisted add-ons. Allowing that is simply infeasible, even setting aside the fact that it's unnecessary. And especially as the new update manifest format (bug 1214058) doesn't even support signatures, this is simply a non-starter.

Comment 13

[Kumar McMillan [:kumar]]

ah, whoops. Yes, update signing vs. extension signing is confusing.