[Go Faster] Default system add-ons and signing

Dave Townsend dtownsend at mozilla.com
Fri Sep 18 22:33:44 UTC 2015

At the moment the plan is to include the most recent versions of any system
add-ons with Firefox at build time. We're also expecting all system add-ons
to be signed by a special signing root. These two things don't work out so
well together. Unless we check in signed versions of system add-ons
whenever they change then developers doing local builds won't be able to
run the system add-ons, also we'll have to figure out some way for releng
builds to sign the add-ons before packaging the app. The problems are
larger for linux distros doing their own builds. None of that sounds good.

Instead I propose that we don't require the system add-ons that ship with
the app to be signed (the updates that download mid-cycle would still be
signed of course). None of the rest of the Firefox code is signed so I
don't know that we need to sign these other bits. We do still want to make
it difficult for malicious apps to use this as a means to inject code into
Firefox. The current client code assumes these system add-ons just live as
XPIs in a directory in the installation directory and any new XPI dropped
in would be used by Firefox (unless we've already downloaded some new
system add-ons mid-cycle). If we're concerns that that is too easy a target
there are a couple of options we could use:

One option is to instead embed the system add-ons inside omni.ja. This
probably has some nice performance wins as it is but it means that in order
to inject a new system add-on in an attacker must alter omni.ja, and if
they're willing to do that then they can just turn off the signing
requirements or even just edit browser.js already anyway.

An even simpler option is to leave the XPIs where they are but include a
file listing the expected add-ons and maybe their hashes in omni.ja. Again
attackers would have to manipulate omni.ja to have any effect, it would be
a simpler attack but it would also be much much simpler to implement this

Any concerns or other ideas for this? How much protection do we feel we
need to put in place around the default system add-ons?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/gofaster/attachments/20150918/3d7f35f4/attachment.html>

More information about the Gofaster mailing list