La vulnérabilité, baptisée Brash, peut faire planter les navigateurs en quelques secondes en inondant l’API document.title, et le silence de Google soulève des questions sur son processus de divulgation.
Une vulnérabilité dans le moteur de rendu de Chromium peut faire planter Chrome, Microsoft Edge et sept autres navigateurs en quelques secondes si elle est exploitée par des attaquants, a averti un chercheur en sécurité après que Google ait ignoré son rapport de vulnérabilité pendant deux mois.
Jose Pino a publié le 29 octobre un code de validation de principe pour la faille, exposant potentiellement plus de trois milliards d’utilisateurs à des pannes de navigateur et à l’instabilité du système. La vulnérabilité exploite une faiblesse fondamentale de la conception de Blink, le moteur de rendu qui alimente tous les navigateurs basés sur Chromium.
Le timing soulève des questions inconfortables sur le processus de réponse aux vulnérabilités de Google. Pino a signalé la faille le 28 août et a donné suite le 30 août. Il n’a reçu aucune réponse avant de décider de publier ses recherches.
« J’ai décidé de publier ce PoC pour attirer l’attention sur un problème grave affectant le grand public après que mon rapport initial il y a deux mois soit resté sans réponse », a déclaré Pino dans la documentation technique publiée sur GitHub. « Je crois que la sensibilisation du public est nécessaire lorsque la divulgation responsable ne produit pas d’atténuation en temps opportun. »
Google, Microsoft et sept autres fournisseurs de navigateurs concernés, dont Opera et Vivaldi, n’ont pas répondu aux demandes de commentaires.
Comment fonctionne l’attaque
La vulnérabilité, que Pino a appelée Brash, exploite l’absence totale de limitation de débit sur les mises à jour de l’API document.title dans Blink. En inondant le navigateur de millions de changements de titre par seconde, un attaquant peut saturer le fil de discussion principal et provoquer un crash.
« Le vecteur d’attaque provient de l’absence totale de limitation de débit sur les mises à jour de l’API document.title », a écrit Pino dans le document technique. « Cela permet d’injecter des millions de mutations DOM par seconde, et lors de cette tentative d’injection, cela sature le thread principal, perturbant la boucle des événements et provoquant l’effondrement de l’interface. »
L’exploit affecte les versions Chromium 143.0.7483.0 et antérieures. Pino a testé 11 navigateurs sur macOS, Windows, Linux et Android. Neuf se sont révélés vulnérables : Chrome, Edge, Vivaldi, Arc, Dia, Opera, Perplexity Comet, ChatGPT Atlas et Brave.
Firefox et Safari en sont sortis indemnes. Les deux utilisent des moteurs de rendu différents – Gecko et WebKit, respectivement – qui ne partagent pas le défaut architectural de Blink. Tous les navigateurs iOS ont également échappé car Apple les oblige à utiliser WebKit, a ajouté Pino dans le document.
Lors des tests de Pino, l’exploit a produit une chronologie d’effondrement prévisible. De zéro à cinq secondes déclenchaient une consommation extrême du processeur. Cinq à 10 secondes ont complètement gelé les onglets. Dix à 15 secondes produisaient un effondrement du navigateur ou des boîtes de dialogue « Page ne répondant pas ». Quinze à 60 secondes ont nécessité une interruption forcée.
Au-delà des pannes de bureau : l’automatisation d’entreprise en danger
Même si les navigateurs en panne perturbent les utilisateurs individuels, la vulnérabilité présente des risques plus importants pour l’automatisation de l’entreprise. Les organisations exécutant des navigateurs Chromium sans tête pour les agents d’IA, les systèmes commerciaux ou la surveillance opérationnelle sont confrontées à une paralysie potentielle des flux de travail, indique le document.
La documentation de Pino décrit plusieurs scénarios d’attaque d’entreprise. Les agents d’IA interrogeant des sites Web compromis pourraient planter en cours d’analyse, interrompant ainsi les décisions de trading automatisées. Les tableaux de bord de détection de fraude pourraient s’effondrer pendant les périodes de pointe des transactions.
Les systèmes de navigation chirurgicale basés sur le Web pourraient tomber en panne lors de procédures critiques. « Le processus du navigateur s’effondre, arrêtant l’ensemble du pipeline d’analyse », selon la documentation de recherche.
Le code de validation de principe de Pino incluait des paramètres de planification permettant aux attaquants de déclencher des plantages à des moments précis. Un attaquant pourrait injecter le code avec un certain délai, le laissant inactif jusqu’à un moment critique : ouverture du marché, changement d’équipe, pic d’activité.
« Une caractéristique essentielle qui amplifie le danger de Brash est sa capacité à être programmé pour s’exécuter à des moments précis », indique la documentation de Pino. « Un attaquant peut injecter le code avec un déclencheur temporel, restant inactif jusqu’à une heure exacte prédéterminée. »
Quand la divulgation échoue
Le silence de Google sur le rapport Pino met en évidence des tensions persistantes dans la divulgation des vulnérabilités. L’équipe Project Zero de Google impose un délai de divulgation strict de 90 jours, la norme de l’industrie, pour les vulnérabilités découvertes dans les logiciels tiers.
La documentation du programme Chrome Vulnerability Reward de la société s’engage à « répondre rapidement et corriger les bogues dans un délai raisonnable ». Il indique que la plupart des bogues de sécurité sont automatiquement ouverts au public 14 semaines après la validation des correctifs dans Chromium.
Mais ce calendrier suppose que les fournisseurs réagissent. Pino n’a reçu aucun accusé de réception de son rapport du 28 août. Son attente de deux mois était bien en deçà de la norme de 90 jours, mais dépassait ce que de nombreux chercheurs considèrent comme raisonnable face au silence des fournisseurs.
Le débat sur la divulgation fait rage depuis des années. Microsoft a un jour critiqué Google pour avoir publié des vulnérabilités de Windows avant que les correctifs ne soient prêts, le qualifiant de « piège » qui exposait les clients. Pourtant, les fournisseurs qui ne répondent pas laissent aux chercheurs peu d’options.
Pino a remarqué une autre complication. « Le problème est plus grave qu’il n’y paraît, puisque chaque entreprise qui utilise Chromium a des fonctionnalités personnalisées, ce qui me porte à croire que le correctif doit être indépendant pour chacune », a-t-il déclaré dans la documentation.
Google a corrigé au moins six vulnérabilités zero-day de Chrome en 2024, selon les avis de sécurité de l’entreprise. Mais ce défaut architectural de Blink n’a reçu aucune reconnaissance publique. Le système de suivi des problèmes publics du projet Chromium ne contenait aucune entrée correspondant à la vulnérabilité au 30 octobre.
Microsoft, Brave et les autres fournisseurs concernés n’avaient émis aucun avis de sécurité au moment de la publication.
Options limitées pour les équipes de sécurité de l’entreprise
Les DSI sont confrontés à des choix difficiles. La vulnérabilité affecte le cœur de Blink, de sorte que les mesures standard de renforcement du navigateur (politiques de sécurité du contenu, isolation du site, restrictions d’extension) n’offrent aucune protection.
Le code de validation de principe de Pino est resté accessible au public sur GitHub sous licences Creative Commons et MIT. La documentation comprenait des clauses de non-responsabilité limitant l’utilisation à la recherche pédagogique et de sécurité dans des environnements contrôlés.
Il a également publié une démonstration en direct sur brash.run qui exécutait l’exploit contre les navigateurs des visiteurs. Le code comprenait des paramètres d’intensité configurables allant des modes d’observation « modérés » aux configurations d’effondrement instantané « extrêmes ».
La documentation précisait que l’exploit cesserait de fonctionner une fois que les fournisseurs auraient corrigé la vulnérabilité. Mais sans délais de réponse de la part de Google ou d’autres fabricants de navigateurs, les équipes de sécurité de l’entreprise n’ont aucun moyen de planifier leurs défenses ou de communiquer les risques aux unités commerciales qui dépendent des flux de travail basés sur les navigateurs.
Ce silence laisse une question cruciale sans réponse : lorsque les fournisseurs ne réagissent pas aux vulnérabilités correctement divulguées, combien de temps les chercheurs doivent-ils attendre avant d’avertir le public ?
