La vulnérabilité a été découverte dans ChromeOS et a un degré de gravité de 9,8 sur 10
Microsoft a publié vendredi dernier des détails techniques sur une vulnérabilité critique de ChromeOS qui pourrait être exploitée pour des attaques par déni de service (DoS) et – dans des cas limités – pour l’exécution de code à distance. Identifiée sous le nom de CVE-2022-2587 (avec un score CVSS de 9,8) et décrite comme une écriture hors limites, la vulnérabilité a été corrigée par la publication d’un correctif en juin. Le problème a été identifié dans le composant CRAS (ChromiumOS Audio Server), et pourrait être déclenché en manipulant les métadonnées associées aux fichiers audios.
ChromeOS est le système d’exploitation propriétaire de Google. Il est basé sur le système d’exploitation open source ChromiumOS, lui-même basé sur Linux. ChromeOS est considéré comme sûr par rapport aux anciens systèmes Windows et macOS. Mais même les systèmes d’exploitation les plus robustes peuvent contenir des bogues de sécurité, comme en témoigne la récente découverte de Microsoft. Dans un billet de blogue détaillé sur la vulnérabilité, Microsoft a déclaré que le bogue a été repéré par Jonathan Bar Or, un des chercheurs en sécurité de son équipe Microsoft 365 Defender Research, fin avril et a été immédiatement signalé à Google.
Le problème découle de l’utilisation de D-Bus, un mécanisme de communication interprocessus (IPC) utilisé dans Linux. Un service D-Bus appelé org.chromium.cras permet d’acheminer l’audio vers des périphériques récemment ajoutés, tels que des haut-parleurs USB et des casques Bluetooth. Ce service comprend une fonction appelée SetPlayerIdentity, qui accepte en entrée une chaîne de caractères appelée identity. Et le code C de la fonction fait appel à strcpy() dans la bibliothèque standard. Pour rappel, la fonction strcpy() permet de copier le contenu d’une chaîne de caractères dans une autre.
Cependant, beaucoup considèrent que l’utilisation de la fonction strcpy() est dangereuse. Par exemple, l’utilisation de cette fonction pour copier un grand tableau de caractère dans un plus petit serait dangereuse, mais si la chaîne de caractère tient, le risque n’en vaut pas la peine. Si la chaîne de destination n’est pas assez grande pour stocker la chaîne source, alors le comportement de la fonction strcpy() est non spécifié ou indéfini. « Pour l’ingénieur en sécurité expérimenté, la mention de la fonction strcpy() déclenche immédiatement des signaux d’alarme », explique Jonathan dans le billet de blogue.
« La fonction strcpy() est connue pour provoquer diverses vulnérabilités de corruption de mémoire puisqu’elle n’effectue aucun contrôle des limites et est donc considérée comme non sûre. Comme il n’y a pas de contrôle de limites sur l’argument identity fourni par l’utilisateur avant d’invoquer strcpy() (outre les limites de longueur de message par défaut pour les messages D-Bus), nous étions sûrs de pouvoir déclencher un dépassement de tampon basé sur le tas, déclenchant ainsi une vulnérabilité de corruption de mémoire », a-t-il ajouté. Selon lui, la faille pourrait être facilement exploitée par un acteur malveillant.
Depuis la ligne de commande, un dépassement de tampon basé sur le tas peut être réalisé simplement en passant une chaîne de 200 caractères à l’utilitaire dbus-send. Et avec un peu plus d’efforts, il a été déterminé que les métadonnées des chansons, transmises au composant de traitement audio de CRAS via la méthode MediaSessionMetadataChanged, pouvaient déclencher le bogue à distance via un navigateur ou Bluetooth. Cependant, Microsoft note que la transformation de ce bogue en un exploit d’exécution de code à distance nécessiterait un toilettage du tas et un enchaînement avec d’autres vulnérabilités.
« L’impact du dépassement de tampon basé sur le tas va du simple DoS au RCE complet. Bien qu’il soit possible d’allouer et de libérer des morceaux par le biais de la manipulation des métadonnées des médias, l’exécution d’un nettoyage précis du tas n’est pas triviale dans ce cas et les attaquants devraient enchaîner l’exploit avec d’autres vulnérabilités pour réussir à exécuter un code arbitraire », explique le billet de blogue. Toutefois, la vulnérabilité semble être suffisamment dangereuse pour justifier la réaction rapide de Google. Jonathan a déclaré que son équipe a été surprise par la rapidité avec laquelle Google a corrigé le bogue.
« Nous avons été impressionnés par la rapidité de la correction et l’efficacité de l’ensemble du processus. En moins d’une semaine, le code a été corrigé et, après plusieurs fusions, mis à la disposition générale des utilisateurs. Nous remercions l’équipe de Google et la communauté Chromium pour leurs efforts dans la résolution de ce problème », a-t-il déclaré. Jonathan a reçu des remerciements du programme de récompense des vulnérabilités de Google, qui lui a attribué en juin 25 000 dollars pour la divulgation responsable du bogue. Microsoft n’a pas trouvé des indicateurs montrant que le bogue a été exploité dans des attaques.
Par ailleurs, le rapport de Microsoft est remarquable à la fois pour la gravité (9,8 sur 10) de la vulnérabilité et pour l’inversion du scénario. C’est généralement Google, en particulier son groupe Project Zero, qui attire l’attention sur les bogues des logiciels Microsoft, en particulier les bogues du système d’exploitation Windows. Selon les analystes, dès 2010, les chercheurs en sécurité de Google ont pris l’habitude de divulguer les bogues des logiciels de Microsoft et d’autres fournisseurs au bout de 90 jours, même si un correctif n’a pas été publié, afin d’obliger les entreprises à réagir plus rapidement aux failles de sécurité.
Microsoft aurait réprimandé Google à ce sujet à plusieurs reprises au fil des ans, même si, dès 2011, la firme de Redmond s’est montrée disposée à s’adapter en révisant sa politique de divulgation des vulnérabilités liées à la sécurité. Cette faille critique de ChromeOS n’est pas une vulnérabilité zero-day puisque Google a effectué les réparations nécessaires. Mais la divulgation permet à Microsoft de souligner avec magnanimité les problèmes du code renforcé d’un concurrent et de féliciter Google pour ses réparations rapides.
source : developpez
