Chrome : que faire lorsqu'une vulnérabilité est exploitée avant que votre parc soit à jour ?

Faits, analyse et incertitudes

Le navigateur, première surface d'attaque du poste de travail

Le navigateur est le seul logiciel d'un poste de travail qui exécute, plusieurs centaines de fois par jour, du code écrit par des inconnus. Chaque page visitée fournit du JavaScript que le moteur compile et exécute. Cette situation est assumée : c'est le fonctionnement du web. Elle est encadrée par deux mécanismes.

• Le processus de rendu

  Le contenu d'un site est traité dans un processus séparé du reste du navigateur, avec des droits réduits. C'est là que s'exécute le code de la page, et c'est la première zone qu'un attaquant cherche à contrôler.

• Le bac à sable

  Ce processus est enfermé dans un bac à sable qui limite fortement ce qu'il peut demander au système. Obtenir l'exécution de code dans le rendu ne donne donc pas encore l'accès au poste.

• La chaîne d'exploitation

  Pour compromettre réellement une machine, un attaquant doit enchaîner une vulnérabilité du moteur avec une seconde permettant de sortir du bac à sable. C'est ce qui rend ces exploits coûteux, donc réservés à des usages ciblés.

Une confusion de types survient lorsque le moteur traite une zone de mémoire comme si elle contenait un type de données alors qu'elle en contient un autre. Les garanties que le moteur tire du type supposé — taille, structure, droits d'accès — ne correspondent plus à la réalité. C'est une porte d'entrée classique vers une capacité de lecture et d'écriture arbitraire dans la mémoire du processus, puis vers l'exécution de code.

Le vrai sujet : l'écart entre correctif disponible et correctif appliqué

Sur un poste isolé, la question est réglée en quelques minutes : Chrome se met à jour seul et redémarre à la prochaine ouverture. Sur un parc géré, quatre étapes distinctes se succèdent, et chacune consomme du temps.

L'étape 3 mérite d'être soulignée, parce qu'elle prend à revers un raccourci courant. Beaucoup de tableaux de bord affichent la version installée sur le disque, et non celle réellement exécutée. Un parc peut apparaître entièrement à jour alors qu'une partie significative des navigateurs tourne encore sur l'ancienne version, parfois depuis plusieurs jours, parce que les utilisateurs ne ferment jamais leur navigateur.

Ce que peut faire un administrateur du parc

Piloter le redémarrage, pas seulement la mise à jour

Chrome Enterprise expose deux stratégies complémentaires. RelaunchNotification détermine si le redémarrage est simplement recommandé ou s'il devient obligatoire à l'issue d'un délai. RelaunchNotificationPeriod fixe ce délai, dont la valeur par défaut est de sept jours. Ramener cette période à quelques dizaines d'heures, en mode obligatoire, transforme la situation sans nécessiter d'outil supplémentaire.

Cette décision a un coût d'acceptabilité : un utilisateur dont le navigateur redémarre perd ses onglets ouverts, même si Chrome les restaure. Elle se prépare donc par une communication, et non par une modification silencieuse de la stratégie un vendredi soir.

Savoir où en est le parc

Le point sur les extensions est le plus négligé. Une extension dispose de droits étendus sur les pages consultées, et elle change de propriétaire sans que personne n'en soit averti. Une politique d'autorisation explicite, limitant les extensions installables à une liste validée, réduit une surface d'attaque qu'aucun correctif de navigateur ne couvre.

Compenser le délai résiduel

• Détection sur le poste

  Une solution de détection sur les points d'accès ne bloque pas l'exploitation du moteur, mais elle voit ce qui se produit ensuite : création de processus inattendue, écriture de fichier, connexion sortante inhabituelle. C'est ce qui reste quand la prévention a échoué.

• Filtrage de la navigation

  Un filtrage des destinations et le blocage des catégories les moins justifiables réduisent le nombre d'occasions de rencontrer une page hostile, sans prétendre à l'exhaustivité.

• Moindre privilège sur le poste

  Un utilisateur sans droits d'administration local limite ce qu'une chaîne d'exploitation réussie peut installer durablement.

• Cloisonnement des usages sensibles

  Les postes d'administration ne devraient pas servir à la navigation courante. Cette séparation, recommandée de longue date, prend tout son sens face à une vulnérabilité de navigateur exploitée.