Au moment de la divulgation de cette vulnérabilité (CVE-2019-17666), Sophos a décidé d’attendre qu’un correctif de sécurité soit disponible avant d’écrire à ce sujet.
Depuis elle a effectivement été corrigée, mais le passage de la découverte au correctif nous a fourni quelques indications sur la manière avec laquelle le projet open source Linux (la plus grande initiative de développement logiciel collaboratif au monde) gère la correction de bugs et les risques de divulgation.
La communauté Linux a travaillé dur le mois dernier pour corriger un bug dans l’un des pilotes sans fil du système d’exploitation. Le problème résidait dans RTLWIFI, un pilote impliqué dans l’utilisation des puces Wi-Fi produites par le fabricant de processeurs Realtek.
Pour être vulnérable vis à vis d’un bug, un appareil doit posséder une puce Realtek Wi-Fi. Ces processeurs peuvent se trouver au niveau de points d’accès Wi-Fi, dans des routeurs et enfin dans certains ordinateurs portables, a expliqué la personne qui l’a découvert, le chercheur principal en sécurité chez GitHub, Nicolas Waisman.
Si un appareil contient cette puce, les conséquences auraient pu être graves, avait-il déclaré à Sophos à l’époque :
Vous pourriez éventuellement obtenir l’exécution de code à distance en tant qu’attaquant.
Un attaquant dans le rayon d’action du périphérique en question pourrait envoyer un paquet en utilisant une fonction Wi-Fi appelée Wi-Fi Direct, qui permet aux périphériques de communiquer directement entre eux par ondes radio sans utiliser un point d’accès central. L’attaquant pourrait ajouter au paquet des informations susceptibles de provoquer un débordement de la mémoire tampon dans le noyau Linux.
Étant donné que les puces Realtek se retrouvent dans toutes sortes d’équipements, y compris des routeurs et des ordinateurs portables, le bug apparaît comme un problème plutôt sérieux. Mais c’est aussi un problème assez ancien : en effet, il est dans le codebase de Linux depuis 2013.
Waisman, un chercheur en sécurité connu avec une bonne réputation et une approche responsable, a révélé le bug avant que l’équipe Linux ne l’ait corrigé, ce qui nous a vraiment surpris et nous a surtout interrogés sur les raisons d’une telle divulgation.
Le mardi 15 octobre 2019, il a informé le groupe via security@kernel.org, une liste de diffusion privée. Deux jours plus tard, il l’a divulgué publiquement sur Twitter, à savoir le 17 octobre. Hors, le correctif développé par l’équipe de sécurité n’a été intégré dans la version v5.3.9 du noyau Linux que le 6 novembre, soit presque trois semaines plus tard !
Found this bug on Monday. An overflow on the linux rtlwifi driver on P2P (Wifi-Direct), while parsing Notice of Absence frames.
The bug has been around for at least 4 years https://t.co/rigXOEId29 pic.twitter.com/vlVwHbUNmf
— Nico Waisman (@nicowaisman) October 17, 2019
La réponse à cette question est qu’après avoir soumis le signalement de ce bug à la liste de diffusion privée security@kernel.org, conformément d’ailleurs à la pratique habituelle, l’équipe de sécurité Linux a envoyé le code, afin d’obtenir une proposition de correctif, via les listes de diffusion ‘Linux Kernel’ et ‘Linux Wireless’, accessibles au public. Une autre proposition publique de correctif a suivi deux jours plus tard.
Waisman a considéré l’exposition de ce code comme une forme de divulgation publique. Il nous a dit : Dès qu’elle apparaît sur la liste de diffusion, tous ceux qui la surveillent sont au courant que cette vulnérabilité existe. Waisman n’a pas développé de code d’exploit pour ce bug. Cependant, une personne malveillante aurait très bien pu s’en charger. Il craignait qu’un individu n’utilise une technique de reverse-engineering pour développer un bug zero-day en parcourant les propositions de correctifs comme celles qui circulaient au sein de la liste de diffusion publique.
En l’annonçant sur Twitter, il pensait utiliser ce qu’il considérait être des pratiques de divulgation responsables, permettant à un plus grand nombre de personnes de prendre des mesures d’évitement (essentiellement en désactivant la fonctionnalité Wi-Fi) jusqu’à ce qu’un correctif ne soit disponible. Un signalement de Mitre (qui gère la base de données CVE) est apparu le même jour avec un lien vers la liste de diffusion publique, et l’entreprise lui a attribué le code CVE suivant : CVE-2019-17666.
Avait-il raison de s’inquiéter ? La communauté considère-t-elle que la publication de propositions de correctifs avant leur intégration dans l’environnement principal du noyau constitue un risque pour la sécurité ? Il existe à priori un risque potentiel, selon les animateurs seniors de l’équipe du noyau Linux.
Greg Kroah-Hartman, membre de la Linux Foundation et responsable des versions stables du noyau Linux, nous a dit que la communauté avait mis en place des procédures permettant de garder secrètes les discussions sur les bugs jusqu’à ce qu’un correctif ne soit disponible :
Concernant certaines questions, oui, il est bon de faire le travail de base pour traiter le problème en question au niveau de la liste security@k.o et ensuite, quand la solution est prête, de la publier et de l’intégrer comme d’habitude. Cette manière de procéder est un classique et est utilisée tout le temps.
Donc, si un bug est assez important et sérieux, l’équipe conservera la discussion au niveau de la liste privée.
Il existe également des mesures supplémentaires que l’équipe du noyau Linux peut prendre pour protéger les discussions concernant des bugs très sérieux. Il existe une liste de diffusion privée (décrite ici) pour communiquer individuellement avec les éditeurs de distribution Linux, leur laissant ainsi le temps de préparer les correctifs du noyau avant la divulgation publique.
Enfin, c’est uniquement à ce moment-là que le code d’un correctif devra être placé sur les référentiels publics qui hébergent le code source du noyau Linux. Se frayer un chemin à travers cette jungle constituée de différentes pièces en attente est un processus complexe. Kroah-Hartmana déclaré que :
Il n’y a aucun moyen de “cacher” notre travail ou nos correctifs car toutes nos activités sont rendues publiques dans nos arborescences. Donc, oui, si vous voulez vraiment voir ce qui est “cassé” dans Linux, vous n’avez qu’à “regarder” simplement tout ce qui vient d’être intégré dans l’arborescence du noyau, car elle reçoit, chaque semaine, des centaines de corrections visant à traiter de nouveaux problèmes.
Linux dispose d’un référentiel de type mainline, maintenu par le créateur du système d’exploitation, Linus Torvalds. Avant qu’un correctif ne soit intégré à ce référentiel, il doit généralement passer par l’un des nombreuses sous-arborescences gérées par des “lieutenants“, qui s’occupent de différents sous-systèmes tels que la gestion du réseau et la mémoire.
Les éditeurs effectuent leur propre contrôle qualité, acceptant ou rejetant les correctifs pour leurs propres arborescences. Ensuite, ils attendent la “fenêtre d’intégration” appropriée, collectent quelques correctifs qui ont bien fonctionné au sein de leur propre arborescence et les offrent à Torvalds en vue d’une possible intégration dans la mainline. L’acceptation définitive ne dépend que de lui.
La mainline sort une nouvelle version “mineure” du noyau Linux toutes les huit semaines environ et, au moment de la rédaction de cet article, la version contenant le correctif pour CVE-2019-17666, à savoir la version 5.4, ne sera disponible que dans une semaine ou deux.
Cependant, lorsque le correctif de sécurité a été accepté au niveau de la mainline, le 23 octobre 2019, il a aussi reçu l’un des feux verts nécessaires pour être rétro-porté vers les versions antérieures du noyau. Une mise à jour de la version 5.3 du noyau, la version stable actuelle, a été publiée le 6 novembre 2019 avec le numéro suivant : 5.3.9.
Comme Kroah-Hartman le laisse supposer, scruter toutes les arborescences pour trouver des correctifs dans l’espoir de mettre la main sur des bugs bien croustillants serait un travail difficile, mais cela ne semble pas non plus impossible pour un adversaire disposant de suffisamment de ressources, qui se ferait aider par un outil appelé ‘-next trees‘, et qui collecterait les correctifs probables pour la prochaine fenêtre d’intégration dans la mainline.
Transformer ces corrections de bugs en exploits opérationnels et utilisables augmenterait sans aucun doute la charge de travail de l’adversaire, mais au final la tâche serait plus difficile que véritablement impossible.
Donc, ce bug est devenu public avant qu’un correctif ne soit disponible car la personne qui l’a trouvé était en désaccord avec les décisions en matière d’exposition prises par les personnes chargées de la maintenance du noyau Linux. Tout le monde avait à cœur de travailler dans l’intérêt de la communauté, mais à présent il existe un correctif qui concerne la plupart des utilisateurs via de nombreuses distributions du noyau.
Bien sûr, c’est une bonne chose qu’un correctif soit disponible, mais c’est encore mieux si les utilisateurs l’installent réellement. Donc, pour les fans de l’interface wlan0, les conseils habituels sont de rigueur : patchez tôt et patchez souvent !
Billet inspiré de How the Linux kernel balances the risks of public bug disclosure, sur Sophos nakedsecurity.
Qu’en pensez-vous ? Laissez un commentaire.