Updated proposal for ensuring add-on update security
Dave Townsend
updates. I have now put together the beginnings of a proposal for how we
will deal with this. It is viewable here:
http://wiki.mozilla.org/User:Mossop:Fx-Docs:AddonUpdateSecurity
I'm sure there will be some points in there that some of you will want
to discuss, I suggest that here is probably a good place since we have
wonderful threading and such. If you do feel the need to put small
comments on the wiki then please do so on the discussion page for the
article, don't edit the main page directly.
Cheers
Dave
Nils Maier
> Do we need to restrict the hashes available? Currently we allow md2, md5, sha1, sha256, sha384 and sha512. Presumably finding a collision that still makes a valid add-on in an xpi file will be quite a challenge.
Yeah, disallow the almost-broken (md2, md5). Crypto experts advice
against using them for new development.
sha-1 is still secure enough, while not fully healthy anymore. But it is
still the standard...
I don't see a point in limiting the use of the shaXXX algorithms. All of
the are secure (enough).
BTW: sha384 and sha512 thru nsICryptoHash are defect except for trunk
were it was fixed. They are incorrectly truncated to first 32 bytes.
This might be worth mentioning in the documentation later ;)
See: https://bugzilla.mozilla.org/show_bug.cgi?id=383390
*Securing Update Manifests Through Digital Signatures*
> What do we do if we have no public key and the update manifest has a signature and it was delivered over SSL?
Hard question.
There are three situations I can easily make up:
1) The install package itself was compromised
2) The original install package is too old (released before the author
decided to add signatures)
3) Simple mistake
Option 1) would mean to disallow the download.
While Option 2) and 3) are likely to happen in the wild as well. I
assume far far more often than 1).
I would say: Allow the update, although this is a (minor) security trade.
> What do we do if we have a public key and the update manifest has no signature but it was delivered over SSL
Hard to decide.
Disallowing the update would mean: You once signed an install package,
then you will always have to sign your updates.rdf or else some of your
users will get no updates and nasty warnings.
Allowing it on the other hand might let a compromised update thru.
Having unsigned SSL after all, I would say imposing stricter rules for
those signing their extensions makes no sense, so allow the update.
> Need to spec out precisely what the signature is signing.
The least you need to sign is the update hash. Everything else does not
really matter. ;)
Would be nice to allow one signature per update not one for the whole
updates.rdf (there might be more than just one update provided by an
updates.rdf)
*Non-conforming Add-ons*
What happens if neither AMO is used nor an updateURL is provided?
Will extensions.checkCompatibility have impact on the checks?
A lot of people will set this switch, especially in the 2.0 -> 3.0
update time.
Extensions like NightlyTesterTools will turn this on for you.
*Migration*
> In order to support updating add-ons which do not currently meet the new requirements there will be the possibility of a single insecure update check for the add-on when the user first updates to Firefox 3.
What happens if said update isn't available at that point yet?
Especially folks using nightlies might be affected by this...
Nils
Tony Mechelynck
No more «version bumping»? And what about the existing extensions (possibly
tested with current Minefield nightlies) which already declare themselves as
"compatible with Fx3"? (See a more detailed comment at
http://wiki.mozilla.org/User_talk:Mossop:Fx-Docs:AddonUpdateSecurity#No_more_%C2%ABversion_bumping%C2%BB_?
-- I hope I didn't mess the URL)
Best regards,
Tony.
--
FIRST GUARD: Ah! Now ... we're not allowed to ...
SIR LAUNCELOT runs him through, grabs his spear and stabs the other
guard who collapses in a heap. Hiccoughs quietly.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
Nickolay Ponomarev
> Many thanks to everyone that replied to my questions about add-on
> updates. I have now put together the beginnings of a proposal for how we
> will deal with this. It is viewable here:
> http://wiki.mozilla.org/User:Mossop:Fx-Docs:AddonUpdateSecurity
>
>>>
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
<<<
This is not strictly required. As someone else said in the other
thread, you can ignore the problem of the update manifest being
hijacked if you check that the new version of an extension is signed
with the same private key as the one already installed.
>>>The update manifest currently contains an optional property, the
updateHash. This will become an absolute requirement for updates.
<<<
Why is this - why servicing the XPI over SSL is not an option here?
>>>In order to support updating add-ons which do not currently meet
the new requirements there will be the possibility of a single
insecure update check for the add-on when the user first updates to
Firefox 3.<<<
It seems more logical to allow insecure updates for extensions with
maxVersion < 3.0bSomething (which is whatever version we'll use when
the feature is implemented).
And just like Tony, I wonder if this will break the nightly tester's
ability to easily bump an extension's maxVersion in order to continue
using it on trunk (in cases when the extension is not hosted on AMO).
Of course you can remove the updateURL from the extension's install
manifest, but that leaves you out of updates. Not sure if it's a big
deal, just saying.
Nickolay
eric...@yahoo.com
updates. I have now put together the beginnings of a proposal for how we
will deal with this. It is viewable here:
http://wiki.mozilla.org/User:Mossop:Fx-Docs:AddonUpdateSecurity<<
I'm not too interested in typing my comments into a new thread, selecting from it only what applies to your modified scheme. Here's the link to the original discussion:
Nils Maier
...
>>>> The update manifest currently contains an optional property, the
> updateHash. This will become an absolute requirement for updates.
> <<<
>
> Why is this - why servicing the XPI over SSL is not an option here?
>
without any way to verify it or the XPI makes Man-in-the-middle attacks
possible where the attacker would serve his own update manifest
containing a link to a compromised XPI on his own (https) server.
Signing all XPIs would render this impossible, but signing an XPI is a
PITA at the moment because you need a valid cert (money, effort and to
some extend invasion of privacy as such a cert will contain your
personal information), time to learn how to use signtool (which isn't
that trivial; you need to use it correct not just use it somehow) and
more effort to sign all your releases, even those going out over your
tester/nightly channels.
Nickolay Ponomarev
> Nickolay Ponomarev schrieb:
> ...
> >>>> The update manifest currently contains an optional property, the
> > updateHash. This will become an absolute requirement for updates.
> > <<<
> >
> > Why is this - why servicing the XPI over SSL is not an option here?
> >
> Simply because serving the update manifest over an insecure connection
> without any way to verify it or the XPI makes Man-in-the-middle attacks
> possible
Um. My understanding is that updateHash provides a way to verify that
the XPI downloaded from the link specified in update.rdf is indeed the
XPI the update manifest's author expected us to get.
Specifying an HTTPS link to the XPI in the update manifest can ensure
people can't use the MITM attack to serve a bad XPI. It doesn't let us
verify the contents of the XPI, but on the other hand there's less
hassle with generating the hashes.
The use case: an extension author, who has a valid certificate and
supports https on his site, and who serves the update manifest and the
XPIs on that site. In case someone malicious can alter the XPI in this
configuration, he can alter the update manifest as well. So there's no
reason to let people use HTTPS without additional hashes for the
update manifest, but not for the XPI.
Nickolay
Nils Maier
Sorry, my mistake.
I wrongly assumed you talked about https for XPI but not necessarily for
update manifest.
Yeah, if both, update manifest and update XPI, are served over https
there is no actual need for that update hash as it won't provide any
additional security (except for "mirror" schemes where different servers
serve the files; see all the annoying link fingerprint discussion :p).
Unrelated, the update hash still might protect against data corruption.
Nils