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.
La fonction vulnérable avec l'invocation de strcpy dans celle-ci
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.
Arbre d'appel montrant comment les changements de métadonnées du navigateur ou du média Bluetooth déclenchent finalement la fonction vulnérable
« 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 : Microsoft
Et vous ?
Quel est votre avis sur le sujet ? Que pensez-vous de cette vulnérabilité critique de ChromeOS ? Que pensez-vous des mises en garde au sujet de la fonction strcpy() du langage C ? Avez-vous déjà rencontré des bogues liés à l'utilisation de cette fonction dans vos applications ?Voir aussi
Steam pour Chrome OS arrive officiellement pour 7 Chromebooks en tant que version alpha et permet de jouer à au moins 50 jeux, mais pas sur les Chromebooks bas de gamme Google soutient un projet Linux visant à rendre Android et Chrome OS plus difficiles à pirater, tout en militant pour l'utilisation de Rust dans le code du noyau La demande de Chromebook s'effondre alors que la pandémie s'atténue, selon un rapport de TrendForce Google pousse les développeurs à adapter les applications Android aux Chromebooks, le nombre d'utilisateurs des applications Android sur des Chromebooks a augmenté de 50 % d'une année sur l'autre 
