1212059 - Don't require shipped system add-ons to be signed, always require updated system add-ons to be signed

Status: RESOLVED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[Dave Townsend [:mossop]]

At the moment both require signing if the pref to enable signing is on. Instead shipped add-ons should never require signing and updates should always require signing.

Comment 1

[Dave Townsend [:mossop]]

Attachment: MozReview Request: Bug 1212059: Don't require shipped system add-ons to be signed, always require updated system add-ons to be signed. r?rhelmer

Bug 1212059: Don't require shipped system add-ons to be signed, always require updated system add-ons to be signed. r?rhelmer

Comment 2

[Daniel Veditz [:dveditz]]

Since Dave met with Richard and I about this issue I'm going to add an explicit review comments so that others with concerns will know we've thought about it.

Signed updates (which live in the user profile) is a no-brainer, the concern is whether it's safe to allow unsigned bits in the install directory. If the install directory is write-protected then user-privileged malware can't side-load anything. But of course installers pretty easily get users to increase their privileges, and in practice it will be very easy to sideload add-ons into this location. This will eventually become a troubling target.

On the other hand, since nothing checks signatures on Firefox binaries (and the all-important omni.ja isn't even signed) it is theoretically possible for such privileged installers to modify Firefox not to do signature checks anyway. (but if we buy that argument why doesn't it hold for signed user add-ons?)

Further mitigation is that Firefox will install with, and then download updates for, a manifest describing which system add-ons should be present and which versions. This manifest is downloaded securely (from certificate-pinned AUS).
  counter-attacks:
    * rewrite the manifest file to list the evil add-on
    * overwrite one of the expected add-ons with an evil twin
    * stop updates of the manifest file

At the next Firefox update some of these changes would be overwritten:
  * a fresh copy of the default manifest is downloaded
  * a fresh copy of all the expected add-ons is downloaded

actually those aren't necessarily true: if the user gets a partial update and we haven't changed the add-on we wouldn't download anything (and many of my user add-ons are stable and go unchanged for ages).

Updates probably don't clear out the system add-on directory (otherwise there would be no partial updates) so if a side-loaded one is present because the manifest was modified it would still be there. The attacker may have to re-raise privileges to modify the manifest again, although more likely they'd just make a copy into the profile.

When we do a Firefox update, how does Firefox know to prefer the fresh manifest that was just installed over one that's in the profile? File modification dates? The attacker can set the modification date for the profile copy far into the future. Preferences? Those live in the profile, too.

Sadly this is going to get abused sooner or later. Can get away with it in the short term but eventually either the add-ons or the manifest will have to be signed. And if you go for signing the manifest it'll have to include file hashes rather than just versions as we talked about (because evil-twin can have a fake version to match) and accurate file hashes are probably as much trouble to get in development builds as signing the add-ons. I think signing the add-ons and then checking-in signed copies will end up being easier. But hey, the point of Go Faster is to decouple development anyway, right? Surely active development lives in some other repo and mozilla-central gets code drops.

If we figure out what we're doing for "developer mode" to allow unsigned user add-ons to work we could possibly piggy-back on that to have unsigned system add-ons work when in that mode. Otherwise plan on reversing this bug in a couple versions.

In the long run I'd like every bit of the Firefox install to be signed and for those signatures to be verified during (or just after?) startup. Today our binaries are signed on Windows and Mac but other important files are not. But afaik nothing checks the signatures we do have unless maybe anti-virus uses them so we've got a long ways to go.

Richard, does that sound about right?

Comment 3

[Robert Helmer [:rhelmer]]

Comment on attachment 8670900 [details]
MozReview Request: Bug 1212059: Don't require shipped system add-ons to be signed, always require updated system add-ons to be signed. r?rhelmer

https://reviewboard.mozilla.org/r/21479/#review19415

Comment 4

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/e2b9c2dc31cd

Comment 5

[Robert Helmer [:rhelmer]]

(In reply to Daniel Veditz [:dveditz] from comment #2)
> But hey, the point of Go Faster is to decouple development anyway,
> right? Surely active development lives in some other repo and
> mozilla-central gets code drops.

That's how it tends to work in practice for Hello/pdf.js/shumway today (the latter two are already developed as add-ons but get dropped into mozilla-central and end up packaged into omni.ja), although Hello does land everything on fx-team regularly.

The current plan is to upload XPIs to AMO be part of the build process as soon as there's an API for this, it's already a potentially-tree-closing dependency on AMO so we could likely download and put the signed copy into the final build too. Alternatively, if this could be done on releng's signing infra, might be fewer moving parts.

I'd rather not make people have to sign and then check in XPIs.

Comment 6

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/e2b9c2dc31cd