Détails techniques du récent crash de l'extension Firefox

À propos de l'auteur. Eric Rescorla - Directeur technique, Groupe Firefox chez Mozilla

Récemment, un incident s'est produit dans Firefox lorsque la plupart des modules complémentaires (extensions, modules complémentaires) ont cessé de fonctionner. Cela est dû à une erreur de notre part: nous n'avons pas remarqué que l'un des certificats, qui est utilisé pour signer les modules complémentaires, a expiré, ce qui a entraîné la déconnexion de la grande majorité d'entre eux. Maintenant que nous avons résolu le problème et que la plupart des modules complémentaires ont été restaurés, je voudrais dire en détail ce qui s'est passé, pourquoi et comment nous l'avons résolu.

Pour référence: les extensions et leur signature

Bien que beaucoup utilisent Firefox tel quel, le navigateur prend également en charge un puissant mécanisme d'extension. Ils ajoutent des fonctionnalités tierces à Firefox qui étendent les fonctionnalités que nous proposons par défaut. Il existe actuellement plus de 15 000 modules complémentaires Firefox: du blocage des publicités à la gestion de centaines d'onglets .

Firefox requiert que tous les modules complémentaires installés soient signés numériquement . Cette exigence vise à protéger les utilisateurs contre les extensions malveillantes en exigeant une norme minimale de vérification par les employés de Mozilla. Avant d'introduire cette exigence en 2015, nous avions de sérieux problèmes avec les extensions malveillantes.

La signature fonctionne via le "certificat racine" préinstallé de Firefox. Il est stocké hors ligne dans le module de sécurité matérielle (HSM) . Toutes les quelques années, il est utilisé pour signer un nouveau «certificat intermédiaire», qui est stocké en ligne et utilisé dans le processus de signature. Lorsque l'extension est soumise pour signature, nous générons un nouveau «certificat d'entité finale» temporaire et le signons avec un certificat intermédiaire. Le certificat de destination est ensuite utilisé pour signer l'extension. Visuellement, cela ressemble à ceci:



Veuillez noter que chaque certificat a un «sujet» (auquel appartient le certificat) et un «éditeur» (signataire). Dans le cas d'un certificat racine, c'est la même chose, mais pour les autres certificats, l'éditeur est le sujet qui l'a signé.

Le point important ici est que chaque module complémentaire est signé avec son propre certificat de l'objet final, mais presque tous les modules complémentaires ont le même certificat intermédiaire (plusieurs modules complémentaires très anciens ont été signés par un autre lien intermédiaire). C'est là que le problème est survenu: chaque certificat a une date d'expiration fixe. Avant ou après cette fenêtre, le certificat ne sera pas accepté et l'extension signée par ce certificat ne pourra pas être téléchargée sur Firefox. Malheureusement, le certificat intermédiaire que nous avons utilisé a expiré le 4 mai après 1h00 UTC, et immédiatement chaque module complémentaire signé par ce certificat est devenu non vérifié et n'a pas pu être téléchargé sur Firefox.

Bien que tous les modules complémentaires soient arrivés à expiration vers une heure du matin, les conséquences n'ont pas été immédiatement ressenties. La raison en est que Firefox ne vérifie pas constamment la validité des modules complémentaires. Ils sont vérifiés environ toutes les 24 heures et le temps de vérification est différent pour chaque utilisateur. En conséquence, certaines personnes ont rencontré des problèmes immédiatement, d'autres beaucoup plus tard. À Mozilla, nous avons appris le problème pour la première fois vers 18 h 00 HNP le vendredi 3 mai et avons immédiatement mis sur pied une équipe pour rectifier la situation.

Limite de dommages

Dès que nous avons compris à quoi nous étions confrontés, nous avons pris plusieurs mesures pour éviter la détérioration de la situation.

Tout d'abord, nous avons désactivé la signature de nouveaux ajouts. À ce moment, c'était raisonnable, car la signature mettait un certificat invalide. En regardant en arrière, il semble qu'il était possible de quitter cette fonction, mais il s'est avéré qu'elle est également en conflit avec l'adoucissement du «firmware de date fixe», dont nous discuterons ci-dessous (bien que nous ne l'ayons pas finalement utilisé). Il est donc bon que nous ayons conservé cette option. Ainsi, la signature de nouveaux ajouts est maintenant retardée.

Deuxièmement, nous avons immédiatement publié un correctif rapide qui supprime la revérification des signatures d'extension. L'idée était de protéger les utilisateurs qui n'ont pas encore été retestés. Nous l'avons fait avant d'avoir un autre correctif, et maintenant supprimé lorsque le correctif est disponible.

Travail parallèle

Théoriquement, la solution à ce problème semble simple: créer un nouveau certificat valide et réémettre chaque ajout avec ce certificat. Malheureusement, nous avons rapidement déterminé que cela ne fonctionnerait pas pour un certain nombre de raisons:

1. Il existe de nombreuses extensions (plus de 15 000), et le service n'est pas optimisé pour la signature en masse, donc la nouvelle signature de chaque module complémentaire prendra plus de temps que nous le voulions.
   
2. Une fois les modules complémentaires signés, les utilisateurs devront obtenir un nouveau module complémentaire. Certains sont hébergés sur des serveurs Mozilla, et Firefox les mettra à jour dans les 24 heures, mais les utilisateurs devront mettre à jour manuellement tous les modules complémentaires installés à partir d'autres sources, ce qui est très gênant.

Au lieu de cela, nous nous sommes concentrés sur le développement d'un correctif qui corrigerait la situation avec peu ou pas d'intervention manuelle des utilisateurs.

Après avoir examiné un certain nombre d'approches, nous nous sommes rapidement mis d'accord sur deux stratégies principales que nous avons menées en parallèle:

1. Patch Firefox pour changer la date utilisée pour vérifier le certificat. Dans ce cas, les modules complémentaires existants fonctionneront à nouveau comme par magie, mais la livraison d'une nouvelle version de Firefox sera nécessaire.
   
2. Générez un nouveau certificat valide et convaincez Firefox de l'accepter au lieu du certificat expiré existant.

Nous n'étions pas sûrs de ce qui fonctionnerait exactement, nous avons donc décidé d'effectuer le travail en parallèle et de mettre en œuvre le premier, qui ressemblerait à une solution de travail. À la fin de la journée, nous avons terminé le déploiement du deuxième correctif - un nouveau certificat, que je décrirai plus en détail.

Certificat de remplacement

Comme mentionné ci-dessus, il y avait deux étapes principales à suivre:

1. Créez un nouveau certificat valide.
   
2. Installez-le à distance dans Firefox.

Pour comprendre pourquoi cela fonctionne, vous devez en savoir un peu plus sur la façon dont Firefox recherche les modules complémentaires. Le module complémentaire lui-même se présente sous la forme d'un package de fichiers, qui comprend la chaîne de certificats utilisée pour le signer. En conséquence, l'addon est vérifié indépendamment si le certificat racine est connu, qui est configuré dans Firefox lors de la génération. Cependant, comme je l'ai dit, le certificat intermédiaire était cassé, donc le module complémentaire n'était pas vraiment vérifiable.

Mais il s'avère que lorsque Firefox essaie de vérifier l'extension, il ne se limite pas à utiliser uniquement des certificats dans l'extension elle-même. Au lieu de cela, il essaie de créer une chaîne de certificats valide, en commençant par le certificat du point de terminaison et en poursuivant vers le répertoire racine. L'algorithme est complexe, mais à un niveau élevé, vous commencez avec un certificat de l'objet final, puis trouvez un certificat dont le sujet est égal à l'éditeur du certificat de l'objet final (c'est-à-dire un certificat intermédiaire). Dans le cas simple, il ne s'agit que d'un lien intermédiaire fourni avec le complément, mais il peut s'agir de n'importe quel certificat connu du navigateur. Si nous pouvons ajouter à distance un nouveau certificat valide, Firefox tentera également de créer une telle chaîne. La figure ci-dessous montre la situation avant et après l'installation d'un nouveau certificat.



Après avoir installé un nouveau certificat, Firefox a deux options pour vérifier la chaîne de certificats: utiliser un ancien certificat invalide (qui ne fonctionnera pas) ou utiliser un 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'objet final est valide. Heureusement, Firefox est assez intelligent pour essayer les deux méthodes jusqu'à ce qu'il en trouve une qui fonctionne, donc l'extension redevient valide. Veuillez noter que c'est la même logique que nous utilisons pour vérifier les certificats TLS, c'est donc un code relativement bien compris que nous avons pu utiliser (les lecteurs familiers avec WebPKI comprendront que la cocertification fonctionne de cette façon).

La grande chose à propos de ce correctif est qu'il ne nécessite aucune modification des extensions existantes. Lorsque nous installons le nouveau certificat dans Firefox, même les extensions avec d'anciens certificats passeront le test. L'astuce pour fournir un nouveau certificat dans Firefox consiste à le faire automatiquement et à distance, puis à faire en sorte que Firefox revérifie toutes les extensions qui peuvent avoir été désactivées.

Normandie et système de recherche

Ironiquement, la solution au problème était un type spécial d'extension appelé add-on système (SAO). Pour les études d'audience (Etudes), nous avons précédemment développé un système appelé Normandy, qui peut délivrer SAO aux utilisateurs de Firefox. Ces SAO sont automatiquement exécutés dans le navigateur de l'utilisateur. Bien qu'ils soient couramment utilisés pour l'expérimentation, ils ont également un large accès aux API internes de Firefox. Dans ce cas, il est important qu'ils puissent ajouter de nouveaux certificats à la base de données de certificats que Firefox utilise pour vérifier les extensions (note technique: nous n'ajoutons pas le certificat avec des privilèges spéciaux; il obtient ses privilèges en signant avec le certificat racine. Nous l'ajoutons simplement au pool de certificats que Firefox peut utiliser, nous n’ajoutons donc pas de nouveau certificat privilégié dans Firefox).

Donc, la solution ici est de créer un SAO qui fait deux choses:

1. Installe le nouveau certificat que nous avons créé.
   
2. Force le navigateur à revérifier chaque module complémentaire pour activer ceux qui se sont déconnectés.

Mais attendez, dites-vous. Les modules complémentaires ne fonctionnent pas, alors comment faire fonctionner SAO? Eh bien, nous le signerons avec un nouveau certificat!

Tout mettre ensemble ... et pourquoi si longtemps?

Alors maintenant, nous avons un plan: émettre un nouveau certificat pour remplacer l'ancien, construire un module complémentaire système pour l'installer dans Firefox et le déployer en Normandie. Nous avons commencé à travailler vers 18 h 00 HNP le vendredi 3 mai et envoyé le patch en Normandie vers 2 h 44, soit moins de 9 heures, puis il a fallu 6 à 12 heures avant que la plupart des utilisateurs ne le reçoivent. C'est en fait un très bon début, mais j'ai vu sur Twitter une série de questions, pourquoi nous ne pouvions pas le faire plus rapidement. Un certain nombre d'étapes prennent du temps.

Premièrement, il a fallu un certain temps pour émettre un nouveau certificat intermédiaire. Comme je l'ai mentionné ci-dessus, le certificat racine est situé dans le module de sécurité matérielle, qui est stocké hors ligne. Il s'agit d'une bonne pratique de sécurité, car vous utilisez très rarement le certificat racine et souhaitez donc le garder en sécurité. Mais évidemment, cela est quelque peu gênant lorsque vous devez émettre un nouveau certificat en cas d'urgence. Dans tous les cas, l'un de nos ingénieurs a dû se rendre dans un endroit sûr où HSM est stocké. Ensuite, il y a eu plusieurs faux départs, lorsque nous n'avons pas pu délivrer le bon certificat, et chaque tentative valait une heure ou deux de test, avant de savoir exactement quoi faire.

Deuxièmement, le développement du système prend un certain temps. Conceptuellement, tout est très simple, mais même les programmes simples nécessitent une certaine prudence, et nous voulions vraiment nous assurer de ne pas aggraver la situation. Et avant d'envoyer SAO, il fallait le tester, et cela prend du temps, d'autant plus qu'il doit être signé. Mais le système de signature était désactivé, nous avons donc dû chercher des solutions de contournement.

Enfin, une fois que le SAO était prêt à être expédié, il a fallu un certain temps pour le déployer. Les clients de Firefox vérifient les mises à jour de Normandy toutes les 6 heures et, bien sûr, de nombreux clients sont hors ligne, de sorte que la mise à jour n'a pas été distribuée instantanément à tous les utilisateurs de Firefox. Cependant, pour le moment, la plupart ont reçu une mise à jour et / ou une nouvelle version, que nous avons publiées plus tard.

Dernières étapes

Bien que l'addon système, déployé via le système des études, devrait corriger la situation pour la plupart des utilisateurs, il n'a pas atteint tout le monde. En particulier, plusieurs types d'utilisateurs nécessitent une approche différente:

• Utilisateurs qui ont désactivé la télémétrie ou la recherche.
  
• Utilisateurs de Firefox pour Android (Fennec), où nous n'avons aucune recherche.
  
• Utilisateurs des versions ultérieures de Firefox ESR qui ne s'abonnent pas aux rapports de télémétrie.
  
• Les utilisateurs qui sont derrière les proxys HTTPS MiTM, car nos systèmes d'installation complémentaires forcent les clés pour ces connexions, ce qui entre en conflit avec le proxy.
  
• Utilisateurs de très anciennes versions de Firefox, auxquelles le système d'études ne peut pas accéder.

Nous ne pouvons rien faire avec le dernier groupe - ils devront effectuer une mise à niveau vers la nouvelle version de Firefox, car les anciennes versions présentent généralement de sérieuses failles de sécurité non corrigées. Nous savons que certaines personnes sont restées sur des versions plus anciennes de Firefox parce qu'elles voulaient exécuter des extensions de style ancien, mais beaucoup d'entre elles fonctionnent maintenant avec des versions plus récentes de Firefox. Pour les autres groupes, nous avons développé un correctif pour Firefox qui installera un nouveau certificat après la mise à niveau. Il est également publié en tant que nouvelle version de Firefox «en pointillés», donc les gens devraient l'obtenir - et probablement déjà le recevoir - via le canal de mise à jour régulier. Si vous avez une version en aval, vous devez attendre la mise à jour du responsable.

Nous reconnaissons que rien de tout cela n'est parfait. En particulier, dans certains cas, les utilisateurs perdent des données associées aux modules complémentaires (par exemple, une extension comme «conteneurs avec plusieurs comptes» ).

Nous n'avons pas pu développer un patch qui évite cet effet secondaire, mais nous pensons qu'à court terme c'est la meilleure approche pour la plupart des utilisateurs. À long terme, nous chercherons les meilleures approches architecturales pour résoudre ces problèmes.

Les leçons

Tout d'abord, je tiens à dire que l'équipe a fait un travail incroyable ici: ils ont développé et envoyé le correctif en moins de 12 heures à partir du moment du rapport initial. En tant que personne qui a assisté à la réunion où cela s'est produit, je peux dire que les gens ont travaillé incroyablement dur dans une situation difficile et que très peu de temps a été perdu.

Compte tenu de cela, il est évident que ce n'est pas une situation idéale, et cela n'aurait pas dû se produire du tout. Nous devons clairement ajuster nos processus pour réduire la probabilité de cet incident et d'incidents similaires et pour faciliter leur correction.

La semaine prochaine, nous procéderons à un débriefing formel et publierons une liste des changements que nous avons l'intention d'apporter, mais pour l'instant, voici mes premières réflexions à ce sujet. Plus important encore, nous devrions avoir un bien meilleur moyen de surveiller l'état de tous les systèmes de Firefox qui sont une bombe à retardement potentielle. Vous devez vous assurer qu'aucun d'entre eux ne s'arrête soudainement de fonctionner. Nous travaillons toujours sur les détails ici, mais au moins nous devons faire l'inventaire de ces systèmes.

Deuxièmement, nous avons besoin d'un mécanisme pour mettre à jour rapidement les utilisateurs, même lorsque - surtout quand - tout le reste ne fonctionne pas. C'est formidable que nous ayons pu utiliser le système des études, mais ce n'était pas non plus l'outil le plus parfait que nous ayons mis en service, et qui a eu des effets secondaires indésirables. En particulier, nous savons que de nombreux utilisateurs ont activé les mises à jour automatiques, mais ils préféreraient ne pas participer à la recherche, et c'est une préférence raisonnable (pour ne rien dire, j'ai configuré le navigateur de cette façon!), Mais en même temps, nous devrions pouvoir pousser mises à jour. Quels que soient les mécanismes techniques internes, les utilisateurs devraient pouvoir sélectionner les mises à jour (y compris les correctifs), mais abandonner tout le reste. De plus, le canal de mise à jour devrait être plus rapide. Même lundi, nous avions encore des utilisateurs qui n'avaient pas récupéré le correctif ou la nouvelle version, ce qui n'est clairement pas parfait. Nous avons déjà travaillé sur ce problème, mais cet incident montre à quel point il est important.

Enfin, nous allons jeter un regard plus général sur notre architecture de sécurité d'extension pour nous assurer qu'elle fournit correctement la sécurité avec un risque minimal d'échec.

La semaine prochaine, nous publierons les résultats d'une analyse plus approfondie de cette situation.