Google Project Zero a déjà signalé des problèmes majeurs dans les propres produits de Google ainsi que dans les produits d’autres sociétés telles que Windows, iPhone, les GPU Qualcomm Adreno, GitHub et autres. Maintenant, il a publiquement signalé un bogue dans Chrome OS après que l’équipe concernée n’a pas réussi à le corriger dans les 90 jours impartis.
La question qui se pose est de savoir comment Chrome OS gère les périphériques USB lorsque le périphérique est verrouillé. Essentiellement, Chrome OS utilise USBGuard pour configurer des listes autorisées et bloquées pour les périphériques USB. Cependant, des paramètres incorrects de cette plate-forme peuvent empêcher les périphériques USB non authentifiés d’accéder au noyau et au stockage du PC.
Comme le décrit Jann Horn, chercheur en sécurité de Google Project Zero , USBGuard dans Chrome OS a une liste noire qui n’authentifie pas les périphériques USB avec certains descripteurs d’interface de classe sur l’écran de verrouillage. Cependant, après cette vérification, toutes les autres interfaces sont autorisées.
Cela signifie que même si un périphérique USB non authentifié sera correctement verrouillé sur l’écran de verrouillage, d’autres périphériques peuvent émuler un périphérique de stockage de masse, modifier le noyau de l’attaquant pour ne pas apparaître en tant que périphérique USB et être authentifiés. En effet, la classe USB n’est pas pertinente pour le noyau, elle permet donc également la modification à partir d’un périphérique apparemment authentifié. Horn note que :
En plus du problème que les pilotes pour les périphériques qui n’appartiennent pas à ces classes d’interface USB ont un grand nombre de surfaces d’attaque, il y a un autre problème avec cette approche : le noyau ne se soucie souvent pas de la classe USB que le périphérique prétend être. être. Les pilotes USB fonctionnent généralement même pour les protocoles standardisés : le pilote indique à faible priorité qu’il souhaite se lier à des périphériques conformes aux normes à l’aide de la classe d’interface USB appropriée, mais indique également à haute priorité qu’il souhaite se lier à des périphériques USB spécifiques basés sur sur Vendor ID et Product ID sans se soucier de leur classe d’interface USB.
[…] Si nous utilisons une machine Linux avec le matériel approprié (j’utilise une carte de développement NET2380, mais vous pouvez probablement aussi le faire avec un téléphone Pixel déverrouillé ou un Raspberry Pi Zero W ou quelque chose de similaire) pour émuler une masse USB Périphérique de stockage utilisant (this) , et corrigez une ligne dans le noyau de l’attaquant afin qu’il emprunte l’identité d’un panneau d’affichage et non d’un périphérique de stockage.
Ce problème a été signalé comme une vulnérabilité de gravité élevée et a été signalé en privé à l’équipe Chrome OS le 24 février. basé sur les pilotes, pas sur les descripteurs d’interface de classe. Le 11 mai, l’équipe Chrome OS a fourni des mises à jour de progression, mais comme elle n’a pas été en mesure de corriger le bogue dans les 90 jours impartis, le problème a été rendu public le 24 mai.
On ne sait pas quand un correctif sera publié, mais il est important de noter qu’il s’agit d’une vulnérabilité locale qui oblige un attaquant à insérer manuellement une clé USB afin de compromettre l’appareil et son noyau. Il ne peut pas être utilisé à distance, mais il agit comme un vecteur d’attaque pour d’autres exploits si vous laissez votre ordinateur Chrome OS sans surveillance, même s’il est verrouillé.
Laisser un commentaire