Microsoft a annoncé son intention de corriger une nouvelle classe de bugs de sécurité Windows découverte par un chercheur de Google Project Zero, et ce même s’il n’a pas trouvé de preuve concluante prouvant que ces derniers représentaient une réelle menace pour les utilisateurs.
Une faiblesse inhabituelle et plutôt complexe semble avoir été négligée dans Windows depuis XP et sera corrigée dans la prochaine version de Windows 10, qui porte actuellement le nom de 19H1 (version 1903).
Mais alors s’il ne s’agit pas d’une menace claire, pourquoi la corriger ? Pour répondre à cette question, nous devons revenir quelque peu en arrière pour en retracer l’historique.
Selon James Forshaw, chercheur dans l’équipe Project Zero, il a découvert pour la première fois, en 2016, ce qu’il supposait être un problème, relativement simple, d’élévation de privilèges au niveau du disque en mode noyau, finalement résolu par Microsoft sous le nom CVE-2016-3219.
Cependant, un an plus tard il a réalisé qu’il était tombé sur une faille logique plus vaste, et qui pouvait permettre aux malwares utilisant le mode utilisateur (qui limitent normalement les privilèges) de se faufiler par le biais de l’interaction de pilotes tiers en mode noyau, de Microsoft et de sous-système de gestion I/O de Windows.
Cependant, Forshaw n’était toujours pas en mesure de créer une preuve de concept fonctionnelle (de nombreux aspects concernant les interactions profondes au niveau du code sont complexes à appréhender sans connaissances adéquates), ce qui l’a obligé à contacter Microsoft pour obtenir de l’aide :
Cette initiative a conduit à des réunions avec différentes équipes lors du Bluehat 2017 à Redmond, où un plan a été mis en place pour que Microsoft utilise son accès au code source afin de découvrir l’étendue de cette catégorie de bugs Windows dans le noyau du système d’exploitation et dans la base de codes des pilotes.
Après avoir effectué de nombreuses interactions avec du code via des outils d’analyse statique, Microsoft a statué en déclarant :
Qu’aucune combinaison d’initiateur et de récepteur [jargon utilisé pour les fonctions d’API] n’était actuellement présente dans les versions prises en charge par Windows et ne pouvait être utilisée pour une élévation locale de privilèges.
Toutefois, étant donné que de nombreux pilotes tiers pouvaient être exploités et que cette classe de bug Windows trouvée par Forshaw semblait si nouvelle et si inattendue, Microsoft a tout de même décidé d’adopter une approche prudente en corrigeant ce problème.
Une possibilité consistait à effectuer une modification complète de l’API, mais elle a été écartée car elle risquait de compromettre les logiciels existants.
En plus de publier un correctif dans la prochaine version de Windows prévue pour avril prochain, Microsoft prévoit de mettre à jour sa documentation de programmation pour attirer l’attention sur ce problème et demande expressément aux développeurs de revoir leur code…
… pour assurer le traitement correct des demandes IRP et l’utilisation défensive des API au niveau des fichiers ouverts.
La paix s’installe
Compte tenu de la façon dont les deux entreprises se sont bagarrées par le passé concernant le calendrier strict de divulgation sous 90 jours de Google, les éloges de Microsoft faites à Forshaw sont plutôt inattendus :
James Forshaw de Google Project Zero est un chercheur qui nous signale régulièrement des vulnérabilités intéressantes et de grande qualité.
Malgré tout, Forshaw de Google n’a pas pu résister à l’envie d’approfondir un peu plus certains éléments spécifiques concernant cette faiblesse :
Il convient de noter que bien que j’ai appliqué le délai de divulgation standard de 90 jours concernant le signalement du serveur SMB, je n’ai pas appliqué de délai particulier concernant le signalement de cette classe de bug Windows.
Victoire donc, du moins pour le moment.
Billet inspiré de Google researcher discovers new type of Windows security weakness, sur Sophos nakedsecurity.