[Go Faster] Updating and installing new system add-ons

Mike Connor mconnor at mozilla.com
Tue Sep 8 19:07:27 UTC 2015


Ok, that cuts off most things. The only other scenario that comes to mind
is someone serving up an intentionally malformed file to exploit something
in our cert validation code.  Ultimately, hashes mean we know it's the
right file before we do anything with it, signing/versioning allows us to
validate contents.  As long as we trust AMO completely.

So, defense in depth argues for hashing, to me, but it may be overkill.

On 8 September 2015 at 13:15, Dave Townsend <dtownsend at mozilla.com> wrote:

> The update xml does include the add-on version to be installed and the
> client will be checking that the add-on it gets has that version.
>
>
> On Tue, Sep 8, 2015 at 10:07 AM, Ben Hearsum <bhearsum at mozilla.com> wrote:
>
>> With a downgrade attack they would take a previously shipped addon (which
>> we validly signed) with a known vulnerbility, and serve that instead of the
>> most recent version. Firefox would see a valid signature, install it, and
>> then the user is vulnerable to whatever exploit is available in that older
>> addon.
>>
>> On Tue, Sep 08, 2015 at 09:58:15AM -0700, Dave Townsend wrote:
>> > Mostly for my own understanding, I'm happy to do hashing anyway, but how
>> > would this help an attacker? They could MITM the CDN but they'd still
>> have
>> > to deliver an XPI signed by the special AMO signing root which is
>> different
>> > to the one that signs normal add-ons. I guess if you want to assume the
>> > worst case of AMO being compromised...
>> >
>> > On Tue, Sep 8, 2015 at 9:54 AM, Ben Hearsum <bhearsum at mozilla.com>
>> wrote:
>> >
>> > > This is a good point. If we only had signatures, and served the bits
>> over
>> > > http, someone could perform a downgrade attack by MITM the CDN that
>> serves
>> > > the bits.
>> > >
>> > > On Tue, Sep 08, 2015 at 12:43:10PM -0400, Mike Connor wrote:
>> > > > Yeah, it's at a minimum backwards compat for updating from older
>> clients.
>> > > >
>> > > > That said, file hashes are a great way of ensuring that we don't
>> get the
>> > > > wrong artifact in transit. It's not necessarily enough to assume
>> that
>> > > > "signed == correct", unless it's prohibitive I think checking that
>> it's
>> > > the
>> > > > correct file is a worthwhile bit of protection.
>> > > >
>> > > > Belt and suspenders FTW.
>> > > >
>> > > > On 8 September 2015 at 12:35, Ben Hearsum <bhearsum at mozilla.com>
>> wrote:
>> > > >
>> > > > > Fine with me as long as the security folks are good with it. Worth
>> > > noting
>> > > > > that we include both hashes plus mar signatures for Gecko updates,
>> > > though
>> > > > > that may simply be because we didn't used to have signed mars...
>> > > > >
>> > > > > On Tue, Sep 08, 2015 at 09:27:51AM -0700, Dave Townsend wrote:
>> > > > > > I was making the assumption that since system add-ons will be
>> signed
>> > > the
>> > > > > > hashes may not be necessary, but that's easy to include if
>> needed.
>> > > > > >
>> > > > > > On Tue, Sep 8, 2015 at 9:22 AM, Ben Hearsum <
>> bhearsum at mozilla.com>
>> > > > > wrote:
>> > > > > >
>> > > > > > > We'll need hashes+filesizes here for verification purposes
>> too, but
>> > > > > that's
>> > > > > > > just a minor detail.
>> > > > > > >
>> > > > > > > On Tue, Sep 08, 2015 at 09:12:43AM -0700, Dave Townsend wrote:
>> > > > > > > > After discussions with Ben I've updated the section of the
>> client
>> > > > > plan on
>> > > > > > > > how we update system add-ons:
>> > > > > > > >
>> > > > > > >
>> > > > >
>> > >
>> https://wiki.mozilla.org/Firefox/Go_Faster/Client_Implementation_Plan#Discovering_system_add-ons
>> > > > > > > >
>> > > > > > > > It shows the actual server response we will be reading and
>> is
>> > > > > essentially
>> > > > > > > > the same update mechanism that GMP uses.
>> > > > > > >
>> > > > > > > > _______________________________________________
>> > > > > > > > Gofaster mailing list
>> > > > > > > > Gofaster at mozilla.org
>> > > > > > > > https://mail.mozilla.org/listinfo/gofaster
>> > > > > > >
>> > > > > > >
>> > > > >
>> > > > > > _______________________________________________
>> > > > > > Gofaster mailing list
>> > > > > > Gofaster at mozilla.org
>> > > > > > https://mail.mozilla.org/listinfo/gofaster
>> > > > >
>> > > > >
>> > > > > _______________________________________________
>> > > > > Gofaster mailing list
>> > > > > Gofaster at mozilla.org
>> > > > > https://mail.mozilla.org/listinfo/gofaster
>> > > > >
>> > > > >
>> > >
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/gofaster/attachments/20150908/e2f5cc26/attachment-0001.html>


More information about the Gofaster mailing list