Patch gap : Mozilla va décaler les correctifs de Firefox pour empêcher l’IA de les transformer en exploits

Un correctif visible dans le code, mais pas encore sur vos postes : une brèche que l'IA sait désormais exploiter dans Firefox. Mozilla riposte. Voici comment.

Par l'intermédiaire de Bobby Holley, Mozilla a dévoilé sa nouvelle stratégie pour faire face à ce que l'on appelle le patch gap. Ce terme n'est pas nouveau : il correspond à la fenêtre entre l'apparition d'un correctif de sécurité dans le code et son déploiement chez la majorité des utilisateurs. Pendant cet intervalle de temps, un attaquant peut alors étudier la modification, remonter jusqu'à la faille et viser les installations non patchées.

Source : Mozilla

Si Mozilla se pose des questions à ce sujet, ce n'est pas un hasard : l'IA change la donne avec le patch gap. Auparavant, cette technique exigeait d'être très bon techniquement et surtout très rapide. Selon Mozilla, des modèles comme GLM 5.3 peuvent exploiter certains correctifs de sécurité découverts par des modèles plus avancés.

Pour rappel, depuis février dernier, l'équipe Firefox traque les failles de sécurité à l'aide des modèles d'Anthropic et d'OpenAI, ce qui a conduit à une explosion du nombre de patchs de sécurité. Le revers de la médaille ? Chaque correctif publié trahit l'emplacement de la faille... C'est d'autant plus vrai lorsque le code est open source.

En parallèle de la publication de Mozilla, une étude d'Epoch AI a illustré le problème. GLM 5.3, modèle open-weight de Z.ai sorti en août, a permis de compromettre 6 versions de Firefox allant de la version 156.0 à la 158.0.1, à partir de correctifs publics pas encore livrés. Ces découvertes ont tout de même un coût évalué à 1 000 dollars par version, et 12 heures de travail effectuées par l'IA pour la tentative la plus rapide. Mais à la clé : un exploit zero-day dans Mozilla Firefox, ce qui n'est pas rien. C'est d'autant plus vrai lorsque la simple visite d'une page piégée suffisait à exfiltrer un fichier local. "Nous n'avons déclenché aucun garde-fou ni aucun refus de la part d'un fournisseur, y compris Z.ai, en utilisant GLM 5.3 de cette manière.", précisent les chercheurs.

Ne jamais livrer les deux pièces du puzzle en même temps

Le navigateur Firefox s'appuie sur plusieurs couches de sandboxing. Ce qui signifie que, dans le cas le plus simple, un attaquant doit enchaîner au moins deux failles : une pour exécuter du code dans le processus de rendu (le renderer, qui exécute le contenu web) et une évasion de la sandbox. Une seule ne suffit pas à compromettre le système.

Mozilla veut en profiter pour contrer le patch gap. Voici l'idée retenue : décaler la publication des correctifs par couche de défense, pour que les patch gaps des différentes couches ne se chevauchent jamais. "À tout moment, un seul des multiples ingrédients nécessaires pour compromettre le navigateur serait disponible dans le patch gap.", explique Bobby Holley. L'attaquant devrait alors dénicher seul au moins une faille inédite.

Ce schéma proposé par Mozilla montre bien cette logique :

Pour autant, la mise en œuvre n'est pas évidente car elle exige une coordination des processus d'ingénierie de Mozilla, et cela pourrait prendre du temps.

Ce qui a déjà changé, et ce que cela implique pour vous

En attendant de mettre ça en place, Mozilla a déjà mis en œuvre certaines actions :

• Des builds chaque semaine : pour rappel, Mozilla a divisé son cycle par deux cette année. Les versions majeures sortent désormais toutes les deux semaines, comme je vous l'expliquais cet été, avec une version corrective entre deux.

• Des tests de régression : Mozilla les garde de nouveau confidentiels jusqu'à la livraison du correctif, GLM 5.3 étant bien moins efficace sans eux.

• Un scan de chaque commit : chaque modification du code est analysée pour repérer les bugs introduits avant leur arrivée dans la version stable.

Et non, Firefox ne fermera pas son code. "Firefox est fièrement open source et nous n'avons aucune intention de changer cela.", précise l'éditeur, pour qui masquer les sources ne serait, au mieux, qu'un ralentisseur face aux outils de rétro-ingénierie.

Côté entreprise, le patch gap a une seconde facette : les postes qui tardent à se mettre à jour. Là, la balle est dans votre camp. Vérifiez que votre parc est au minimum en Firefox 159.0.1, publié le 3 novembre (ESR 153.6 ou 115.44 pour le canal ESR, voir les bulletins de sécurité de Mozilla).

Enfin, la réflexion menée par Mozilla autour du patch gap est légitime et pertinente. D'autres éditeurs se posent forcément les mêmes questions.

Qu'en pensez-vous ?

Ajouter IT-Connect à mes
sources préférées

Cofondateur d'IT-Connect et Microsoft MVP "Cloud and Datacenter Management". Mon obsession depuis près de 15 ans ? Rendre l'administration système et la cybersécurité accessibles, que vous soyez junior ou confirmé. Plus qu'un métier, l'IT est pour moi une véritable passion. J’accompagne au quotidien les sysadmins et les professionnels de l’IT dans leur montée en compétences et leur veille technique.