Récemment, Firefox a eu un incident dans lequel la plupart des add-ons ont cessé de fonctionner. Cela était dû à une erreur de Mozilla : la fondation a laissé expirer l'un des certificats utilisés pour signer les add-ons, ce qui a eu pour effet de désactiver la grande majorité des add-ons. Maintenant que le problème est résolu pour la plupart des utilisateurs et que la plupart des add-ons ont été restaurés, Mozilla a souhaité expliquer en détail ce qui est arrivé et pourquoi ainsi que la façon dont la fondation a corrigé son erreur.
Modules complémentaires et signature de modules complémentaires
Firefox prend en charge un mécanisme d'extension appelé « add-ons » (modules complémentaires). Les modules complémentaires permettent aux utilisateurs d’ajouter à Firefox des fonctionnalités tierces qui étendent les fonctionnalités proposées par défaut. Il existe actuellement plus de 15 000 add-ons Firefox dotés de fonctionnalités allant du blocage d'annonces à la gestion de centaines d'onglets.
Firefox nécessite que tous les add-ons installés soient signés numériquement. Cette exigence vise à protéger les utilisateurs contre les add-ons malveillants en imposant un minimum de révision par le personnel de Mozilla. Avant d'introduire cette exigence en 2015, Firefox avait de sérieux problèmes avec les add-ons malveillants.
La façon dont fonctionne la signature complémentaire est que Firefox est configuré avec un « certificat racine » préinstallé. Cette racine est stockée hors ligne dans un module de sécurité matérielle (HSM - hardware security module). Il est utilisé pour signer un nouveau « certificat intermédiaire » qui est conservé en ligne et utilisé dans le cadre du processus de signature pendant quelques années. Lorsqu'un module complémentaire est présenté à la signature, Mozilla génère un nouveau « certificat d'entité finale » temporaire et le signe à l'aide du certificat intermédiaire. Le certificat d'entité finale est ensuite utilisé pour signer le module complémentaire lui-même. Visuellement, cela ressemble à ceci:
Notez que chaque certificat a un “sujet” (à qui le certificat appartient) et un “émetteur” (le signataire). Dans le cas de la racine, il s'agit de la même entité, mais pour d'autres certificats, l'émetteur d'un certificat est le sujet du certificat qui l'a signé.
Un point important ici est que chaque add-on est signé par son propre certificat d'entité finale, mais presque tous les add-ons partagent le même certificat intermédiaire. C'est ce certificat qui a rencontré un problème : chaque certificat a une période de validité pendant laquelle il est valide. Avant ou après cette fenêtre, le certificat ne sera pas accepté et un add-on signé avec ce certificat ne pourra pas être chargé dans Firefox. Malheureusement, le certificat intermédiaire que Firefox utilisait a expiré le 4 mai et, immédiatement, tous les add-ons signés avec ce certificat ne pouvaient plus être vérifiables, ce qui fait que Firefox n’était plus en mesure de les charger.
« Bien que tous les ajouts aient expiré vers minuit, l’impact de la panne n’a pas été immédiatement ressenti. La raison en est que Firefox ne vérifie pas en permanence la validité des add-ons. Au lieu de cela, tous les add-ons sont vérifiés environ toutes les 24 heures, l'heure de la vérification étant différente pour chaque utilisateur. Le résultat est que certaines personnes ont immédiatement rencontré des problèmes, d’autres seulement beaucoup plus tard. Chez Mozilla, nous avons pris conscience du problème le vendredi 3 mai vers 18 heures, heure du Pacifique. Nous avons immédiatement constitué une équipe chargée de tenter de résoudre le problème ».
Limiter les dommages
Une fois que Mozilla a compris ce à quoi elle étions confrontés, la fondation a pris plusieurs mesures pour éviter que la situation ne s'aggrave.
Tout d’abord, elle a la signature de nouveaux add-ons. C'était raisonnable à ce moment car les signatures étaient effectuées sur Firefox avec un certificat qui était expiré. Rétrospectivement, la fondation reconnaît qu’abandonner les signatures aurait pu fonctionner. Cependant, si elle avait opté pour cette solution, ce chemin allait alors interférer avec une atténuation qu’elle a envisagé plus bas mais n’a finalement pas utilisé).
Ensuite, Mozilla a immédiatement mis en place un correctif qui empêchait de valider à nouveau les signatures sur les add-ons. L’idée ici était d’éviter d’avoir des utilisateurs désemparés parmi ceux qui n’avaient pas encore vu une nouvelle validation de leur certificat. Mozilla l’a fait avant de disposer de tout autre correctif et l'a supprimé dès lors que les correctifs étaient disponibles.
Travailler en parallèle
« En théorie, résoudre un problème comme celui-ci semble simple : créer un nouveau certificat valide et publier à nouveau chaque module complémentaire avec ce certificat. Malheureusement, nous avons rapidement déterminé que cela ne fonctionnerait pas pour plusieurs raisons:
Il existe un très grand nombre d’add-ons (plus de 15 000) et le service de signature n’est pas optimisé pour la signature en bloc. Par conséquent, une nouvelle signature de chaque add-on prendrait plus de temps que nous le souhaitions.
Une fois les add-ons signés, les utilisateurs devraient en obtenir un nouveau. Certains modules complémentaires sont hébergés sur les serveurs de Mozilla et Firefox les mettrait à jour dans les 24 heures, mais les utilisateurs devraient mettre à jour manuellement les modules installés à partir d’autres sources, ce qui ne serait pas très pratique.
« Au lieu de cela, nous nous sommes attachés à essayer de développer un correctif que nous pourrions fournir à tous nos utilisateurs avec une intervention manuelle minime, voire aucune.
« Après avoir examiné plusieurs approches, nous avons rapidement convergé sur deux stratégies majeures que nous avons poursuivies en parallèle:
- Déployer un correctif Firefox pour changer la date utilisée pour valider le certificat. Cela ferait fonctionner les modules complémentaires existants comme par magie, mais nécessiterait de fournir une nouvelle version de Firefox (une «dot release»).
- Générer un certificat de remplacement qui était toujours valide et persuader Firefox de l'accepter au lieu du certificat existant ayant expiré.
« Nous n'étions pas sûrs que l'un ou l'autre fonctionnerait, nous avons donc décidé de les poursuivre en parallèle et de déployer le premier qui semblait vouloir fonctionner. À la fin, nous avons fini par déployer le deuxième correctif, le nouveau certificat ».
Un certificat de remplacement
Comme suggéré ci-dessus, Mozilla a suivi deux étapes principales:
- Générer un nouveau certificat valide.
- L’installer à distance dans Firefox.
Afin de comprendre pourquoi cela fonctionne, vous devez en savoir un peu plus sur la manière dont Firefox valide les add-ons. Le module complémentaire lui-même est constitué d’un ensemble de fichiers comprenant la chaîne de certificats utilisée pour le signer. Le résultat est que le module complémentaire est vérifiable indépendamment tant que vous connaissez le certificat racine, qui est configuré dans Firefox au moment de la build. Cependant le certificat intermédiaire était cassé et l’add-on n’était donc pas vérifiable.
Il s'avère que lorsque Firefox essaie de valider le module complémentaire, il ne se limite pas à l’utilisation des certificats contenus dans le module complémentaire. Au lieu de cela, il essaie de créer une chaîne de certificats valide en commençant par le certificat d'entité finale et en continuant jusqu'à la racine. L'algorithme est compliqué, mais à un niveau élevé, vous commencez par le certificat d'entité finale, puis recherchez un certificat dont le sujet est égal à l'émetteur du certificat d'entité finale (c'est-à-dire, le certificat intermédiaire). Dans le cas simple, il s’agit de l’intermédiaire fourni avec l’add-on, mais il peut s’agir de n’importe quel certificat connu du navigateur. Si Mozilla peut ajouter à distance un nouveau certificat valide, alors Firefox le tentera également. La figure ci-dessous montre la situation avant et après l'installation du nouveau certificat.
« Une fois le nouveau certificat installé, Firefox a le choix entre deux manières de valider la chaîne de certificats : utiliser l’ancien certificat non valide (qui ne fonctionnera pas) et utiliser le nouveau certificat valide (qui fonctionnera). Une caractéristique importante ici est que le nouveau certificat a le même nom de sujet et la même clé publique que l'ancien certificat, de sorte que sa signature sur le certificat de l'entité finale est valide. Heureusement, Firefox est assez intelligent pour essayer les deux jusqu'à trouver un chemin qui fonctionne, de sorte que le module complémentaire redevient valide. Notez que c’est la même logique que nous utilisons pour la validation des certificats TLS, c’est donc un code relativement bien compris que nous avons pu exploiter.
« L’avantage de ce correctif est qu’il ne nous oblige pas à modifier les add-on existants. Tant que nous recevons le nouveau certificat dans Firefox, les add-ons portant l’ancien certificat seront automatiquement vérifiés. La difficulté consiste alors à importer le nouveau certificat dans Firefox, ce que nous devons faire automatiquement et à distance, puis à ce que Firefox revérifie tous les add-ons éventuellement désactivés ».
Le système d'études
Ironiquement, la solution à ce problème est un type spécial de module complémentaire appelé module complémentaire système (SAO). Afin de mener des études de recherche, Mozilla a développé un système appelé Normandy qui lui permet de servir les SAO aux utilisateurs de Firefox. Ces SAO s’exécutent automatiquement sur le navigateur de l’utilisateur. Bien qu’ils soient généralement utilisés pour des expériences, ils disposent également d’un accès étendu aux API internes de Firefox. Ce qui est important dans ce cas, c’est qu’ils peuvent ajouter de nouveaux certificats à la base de données de certificats utilisée par Firefox pour vérifier les modules complémentaires.
La solution ici est donc de construire un SAO qui fait deux choses:
- Installer le nouveau certificat que Mozilla a créé.
- Forcer le navigateur à revérifier chaque add-on pour que ceux qui ont été désactivés deviennent actifs.
Étapes finales
Si le SAO déployé avec Studies devait résoudre le problème de la plupart des utilisateurs, il n’a pas touché tout le monde. En particulier, plusieurs types d’utilisateurs affectés ont nécessité une autre approche:
- Les utilisateurs ayant désactivé la télémétrie ou les études.
- Les utilisateurs sur Firefox pour Android (Fennec), où Mozilla n'a pas d'études.
- Les utilisateurs de versions downstream de Firefox ESR qui n’acceptent pas de rapport de télémétrie.
- Les utilisateurs qui se trouvent derrière des proxies HTTPS Man-in-the-middle, car les systèmes d’installation complémentaires de Mozilla imposent l’épinglage de clés pour ces connexions, auxquelles les proxies interfèrent.
- Les utilisateurs de très anciennes versions de Firefox que le système d’études ne peut atteindre.
« Nous ne pouvons vraiment rien faire avec le dernier groupe. Ils doivent quand même passer à une nouvelle version de Firefox car les anciennes versions comportent généralement de graves vulnérabilités non résolues en matière de sécurité. Nous savons que certaines personnes ont conservé les anciennes versions de Firefox car elles souhaitent utiliser des modules complémentaires de style ancien, mais bon nombre d’entre elles fonctionnent désormais avec les versions les plus récentes de Firefox. Pour les autres groupes, nous avons développé un correctif pour Firefox qui installera le nouveau certificat une fois les personnes mises à jour. Cela a été publié comme une "dot release" afin que les gens puissent l'obtenir - et l'ont probablement déjà obtenu - via le canal de mise à jour ordinaire.
« Nous reconnaissons que rien de tout cela n'est parfait. Dans certains cas, en particulier, les utilisateurs ont perdu des données associées à leurs add-ons (un exemple ici est l'add-on «Conteneurs multi-comptes»).
« Nous n’avons pas été en mesure de mettre au point un correctif qui éviterait cet effet secondaire, mais nous pensons que c’est la meilleure approche à court terme pour la plupart des utilisateurs. À long terme, nous rechercherons de meilleures approches architecturales pour traiter ce type de problème ».
Source : Mozilla
Voir aussi :
Firefox : les extensions contenant du code masqué seront désormais interdites, d'après une MàJ des conditions d'utilisation destinée aux développeurs Firefox 68 Nightly et Firefox Bêta 67 débarquent avec des protections intégrées contre le fingerprinting et le cryptojacking Pwn2Own 2019 : Tesla, Firefox, Safari, Microsoft Edge et Windows 10 ont été piratés, et les chercheurs qui ont piraté la Tesla peuvent la garder Firefox 66 s'accompagne du blocage des vidéos en lecture automatique avec le son activé, et la prise en charge de l'API Web Authentication Une nouvelle extension de Windows Defender Application Guard pour Chrome et Firefox ouvre des sites non approuvés dans Microsoft Edge 
Envoyé par edrobal
) et même pas eu les extensions désactivées sur de vieilles versions de Firefox, dont la ESR 52* (contrairement à d'autres personnes !).
