Liste de contrôle de sécurité des pilotes
Cet article fournit une liste de contrôle de sécurité des pilotes pour les développeurs de pilotes afin de réduire le risque de compromission des pilotes.
Vue d’ensemble de la sécurité des pilotes
Une faille de sécurité est toute faille qui permet à un attaquant de provoquer un dysfonctionnement d’un pilote de telle sorte qu’elle provoque le blocage du système ou devient inutilisable. En outre, les vulnérabilités dans le code du pilote peuvent permettre à un attaquant d’accéder au noyau, ce qui crée une possibilité de compromettre l’ensemble du système d’exploitation. Lorsque la plupart des développeurs travaillent sur leur pilote, ils se concentrent sur le bon fonctionnement du pilote et non sur la tentative d’exploitation des vulnérabilités de leur code par un attaquant malveillant.
Toutefois, une fois qu’un pilote est libéré, les attaquants peuvent tenter de sonder et d’identifier les failles de sécurité. Les développeurs doivent tenir compte de ces problèmes pendant la phase de conception et d’implémentation afin de réduire la probabilité de telles vulnérabilités. L’objectif est d’éliminer toutes les failles de sécurité connues avant que le pilote ne soit libéré.
La création de pilotes plus sécurisés nécessite la coopération de l’architecte système (en pensant consciemment aux menaces potentielles pour le pilote), du développeur qui implémente le code (codage défensif des opérations courantes qui peuvent être la source d’exploits) et de l’équipe de test (en essayant de rechercher de manière proactive les faiblesses et les vulnérabilités). En coordonnant correctement toutes ces activités, la sécurité du conducteur est considérablement améliorée.
En plus d’éviter les problèmes associés à l’attaque d’un pilote, de nombreuses étapes décrites, telles que l’utilisation plus précise de la mémoire du noyau, augmenteront la fiabilité de votre pilote. Cela permettra de réduire les coûts de support et d’augmenter la satisfaction des clients à l’égard de votre produit. L’exécution des tâches de la liste de contrôle ci-dessous vous aidera à atteindre tous ces objectifs.
Liste de contrôle de sécurité :effectuez la tâche de sécurité décrite dans chacune de ces rubriques.
Vérifier qu’un pilote de noyau est requis
Utiliser les infrastructures de pilote
Contrôler l’accès aux pilotes logiciels uniquement
Ne pas signer de production code du pilote de test
Effectuer une analyse des menaces
Suivez les instructions de codage sécurisé du pilote
Implémenter du code compatible HVCI
Suivre les meilleures pratiques en matière de code spécifique à la technologie
Effectuer une révision du code d’homologue
Gérer le contrôle d’accès aux pilotes
Améliorer la sécurité de l’installation de l’appareil
Exécuter une signature de pilote de mise en production appropriée
Utiliser l’analyse du code dans Visual Studio pour examiner la sécurité des pilotes
Utiliser le vérificateur de pilotes statique pour case activée des vulnérabilités
Vérifier le code avec BinSkim Binary Analyzer
Utiliser les outils de validation de code
Passer en revue les techniques et extensions du débogueur
Passer en revue les ressources de codage sécurisé
Passez en revue le résumé des principaux points à retenir
Vérifier qu’un pilote de noyau est requis
Élément de la liste de contrôle de sécurité n°1 :Vérifiez qu’un pilote de noyau est nécessaire et qu’une approche à moindre risque, telle que le service ou l’application Windows, n’est pas une meilleure option.
Les pilotes vivent dans le noyau Windows, et un problème lors de l’exécution dans le noyau expose l’ensemble du système d’exploitation. Si une autre option est disponible, elle sera probablement moins coûteuse et moins risquée que la création d’un nouveau pilote de noyau. Pour plus d’informations sur l’utilisation des pilotes Windows intégrés, consultez Devez-vous écrire un pilote ?.
Pour plus d’informations sur l’utilisation des tâches en arrière-plan, consultez Prise en charge de votre application avec des tâches en arrière-plan.
Pour plus d’informations sur l’utilisation des services Windows, consultez Services.
Utiliser les infrastructures de pilote
Élément de la liste de contrôle de sécurité n° 2 :Utilisez les infrastructures de pilote pour réduire la taille de votre code et augmenter sa fiabilité et sa sécurité.
Utilisez windows Driver Frameworks pour réduire la taille de votre code et augmenter sa fiabilité et sa sécurité. Pour commencer, consultez Utilisation de WDF pour développer un pilote. Pour plus d’informations sur l’utilisation du pilote d’infrastructure en mode utilisateur (UMDF) à faible risque, consultez Choix d’un modèle de pilote.
L’écriture d’un pilote WDM (Windows Driver Model) ancien est plus chronophage, coûteuse et implique presque toujours de recréer du code disponible dans les infrastructures de pilote.
Le code source de Windows Driver Framework est open source et disponible sur GitHub. Il s’agit du même code source à partir duquel la bibliothèque runtime WDF fournie dans Windows 10 est générée. Vous pouvez déboguer votre pilote plus efficacement lorsque vous pouvez suivre les interactions entre le pilote et WDF. Téléchargez-le à partir de https://github.com/Microsoft/Windows-Driver-Frameworks.
Contrôler l’accès aux pilotes logiciels uniquement
Élément de la liste de contrôle de sécurité #3 :Si un pilote logiciel uniquement est créé, un contrôle d’accès supplémentaire doit être implémenté.
Les pilotes de noyau logiciel uniquement n’utilisent pas plug-and-play (PnP) pour être associés à des ID matériels spécifiques et peuvent s’exécuter sur n’importe quel PC. Un tel pilote peut être utilisé à des fins autres que celles prévues à l’origine, créant un vecteur d’attaque.
Étant donné que les pilotes de noyau logiciel uniquement présentent des risques supplémentaires, ils doivent être limités à s’exécuter sur un matériel spécifique (par exemple, en utilisant un ID PnP unique pour permettre la création d’un pilote PnP ou en vérifiant la présence de matériel spécifique dans la table SMBIOS).
Par exemple, imaginez que fabrikam OEM souhaite distribuer un pilote qui active un utilitaire d’overclocking pour ses systèmes. Si ce pilote logiciel uniquement s’exécute sur un système à partir d’un autre oem, il peut en résulter une instabilité ou des dommages du système. Les systèmes de Fabrikam doivent inclure un ID PnP unique pour permettre la création d’un pilote PnP qui peut également être mis à jour via Windows Update. Si cela n’est pas possible et que Fabrikam crée un pilote hérité, ce pilote doit trouver une autre méthode pour vérifier qu’il s’exécute sur un système Fabrikam (par exemple, en examinant la table SMBIOS avant d’activer les fonctionnalités).
Ne pas produire de code de test de signe
Élément de la liste de contrôle de sécurité n° 4 :Ne pas produire le code de développement, de test et de fabrication du code de pilote du noyau.
Le code de pilote du noyau utilisé pour le développement, le test ou la fabrication peut inclure des fonctionnalités dangereuses qui posent un risque de sécurité. Ce code dangereux ne doit jamais être signé avec un certificat approuvé par Windows. Le mécanisme approprié pour exécuter un code de pilote dangereux consiste à désactiver le démarrage sécurisé UEFI, à activer le BCD « TESTSIGNING » et à signer le code de développement, de test et de fabrication à l’aide d’un certificat non approuvé (par exemple, un certificat généré par makecert.exe).
Le code signé par un certificat d’éditeur de logiciels (SPC) approuvé ou une signature WHQL (Hardware Quality Labs) windows ne doit pas faciliter le contournement des technologies d’intégrité et de sécurité du code Windows. Avant que le code ne soit signé par une signature SPC ou WHQL approuvée, vérifiez d’abord qu’il est conforme aux instructions de Création de pilotes Kernel-Mode fiables. En outre, le code ne doit pas contenir de comportements dangereux, décrits ci-dessous. Pour plus d’informations sur la signature de pilote, consultez Mise en production de la signature du pilote plus loin dans cet article.
Voici des exemples de comportement dangereux :
- Fournir la possibilité de mapper la mémoire arbitraire du noyau, physique ou de l’appareil en mode utilisateur.
- Permettant de lire ou d’écrire de la mémoire arbitraire du noyau, de la mémoire physique ou de l’appareil, y compris l’entrée/sortie de port (E/S).
- Fournir un accès au stockage qui contourne le contrôle d’accès Windows.
- Fournir la possibilité de modifier le matériel ou le microprogramme que le pilote n’a pas été conçu pour gérer.
Effectuer une analyse des menaces
Élément de la liste de contrôle de sécurité n° 5 :Modifiez un modèle de menace de pilote existant ou créez un modèle de menace personnalisé pour votre pilote.
En ce qui concerne la sécurité, une méthodologie courante consiste à créer des modèles de menace spécifiques qui tentent de décrire les types d’attaques possibles. Cette technique est utile lors de la conception d’un pilote, car elle force le développeur à prendre en compte les vecteurs d’attaque potentiels contre un pilote à l’avance. Après avoir identifié les menaces potentielles, un développeur de pilotes peut ensuite envisager des moyens de se défendre contre ces menaces afin de renforcer la sécurité globale du composant pilote.
Cet article fournit des conseils spécifiques aux pilotes pour la création d’un modèle de menace léger : Modélisation des menaces pour les pilotes. L’article fournit un exemple de diagramme de modèle de menace de pilote qui peut être utilisé comme point de départ pour votre pilote.
Les meilleures pratiques SDL (Security Development Lifecycle) et les outils associés peuvent être utilisés par les IVS et les oem pour améliorer la sécurité de leurs produits. Pour plus d’informations, consultez Recommandations SDL pour les oem.
Suivez les instructions de codage sécurisé du pilote
Élément de la liste de contrôle de sécurité 6 :Passez en revue votre code et supprimez les vulnérabilités connues du code.
L’activité principale de la création de pilotes sécurisés consiste à identifier les zones du code qui doivent être modifiées pour éviter les vulnérabilités logicielles connues. Bon nombre de ces vulnérabilités logicielles connues traitent du suivi strict de l’utilisation de la mémoire afin d’éviter les problèmes avec d’autres personnes qui remplacent ou composent les emplacements de mémoire utilisés par votre pilote.
La section Outils de validation de code de cet article décrit les outils logiciels qui peuvent être utilisés pour aider à localiser les vulnérabilités logicielles connues.
Mémoire tampons
Toujours case activée les tailles des mémoires tampons d’entrée et de sortie pour vous assurer que les mémoires tampons peuvent contenir toutes les données demandées. Pour plus d’informations, consultez Échec de la vérification de la taille des mémoires tampons.
Initialisez correctement toutes les mémoires tampons de sortie avec des zéros avant de les renvoyer à l’appelant. Pour plus d’informations, consultez Échec de l’initialisation des tampons de sortie.
Valider les mémoires tampons de longueur variable. Pour plus d’informations, consultez Échec de la validation Variable-Length tampons. Pour plus d’informations sur l’utilisation des mémoires tampons et l’utilisation de ProbeForRead et ProbeForWrite pour valider l’adresse d’une mémoire tampon, consultez Gestion des mémoires tampons.
Utiliser la méthode appropriée pour accéder aux mémoires tampons de données avec des IOCTL
L’une des principales responsabilités d’un pilote Windows est le transfert de données entre les applications en mode utilisateur et les appareils d’un système. Les trois méthodes d’accès aux mémoires tampons de données sont indiquées dans le tableau suivant.
| Type de mémoire tampon IOCTL | Résumé | Informations supplémentaires |
|---|---|---|
| METHOD_BUFFERED | Recommandé pour la plupart des situtations | Utilisation des E/S mises en mémoire tampon |
| METHOD_IN_DIRECT ou METHOD_OUT_DIRECT | Utilisé dans certaines E/S HW à grande vitesse | Utilisation d’E/S directes |
| METHOD_NEITHER | Éviter si possible | Utilisation de ni d’E/S en mémoire tampon ni d’E/S directes |
En général, les E/S mises en mémoire tampon sont recommandées, car elles fournissent les méthodes de mise en mémoire tampon les plus sécurisées. Toutefois, même lors de l’utilisation d’E/S mises en mémoire tampon, il existe des risques, tels que les pointeurs incorporés, qui doivent être atténués.
Pour plus d’informations sur l’utilisation des mémoires tampons dans iocTL, consultez Méthodes d’accès aux mémoires tampons de données.
Erreurs d’utilisation des E/S en mémoire tampon IOCTL
Vérifiez la taille des mémoires tampons associées à IOCTL. Pour plus d’informations, consultez Échec de la vérification de la taille des mémoires tampons.
Initialisez correctement les mémoires tampons de sortie. Pour plus d’informations, consultez Échec de l’initialisation des tampons de sortie.
Validez correctement les mémoires tampons de longueur variable. Pour plus d’informations, consultez Échec de la validation Variable-Length tampons.
Lorsque vous utilisez des E/S mises en mémoire tampon, veillez à renvoyer la longueur appropriée pour outputBuffer dans le champ Informations de la structure IO_STATUS_BLOCK . Ne retournez pas directement la longueur directement à partir d’une requête READ. Par exemple, considérez une situation où les données retournées à partir de l’espace utilisateur indiquent qu’il existe une mémoire tampon 4K. Si le pilote ne doit réellement renvoyer que 200 octets, mais qu’il retourne simplement 4K dans le champ Informations, une vulnérabilité de divulgation d’informations s’est produite. Ce problème se produit car dans les versions antérieures de Windows, la mémoire tampon utilisée par le Gestionnaire d’E/S pour les E/S mises en mémoire tampon n’est pas mise à zéro. Ainsi, l’application utilisateur récupère les 200 octets de données d’origine plus 4 000 à 200 octets de ce qui se trouvait dans la mémoire tampon (contenu du pool non paginé). Ce scénario peut se produire avec toutes les utilisations d’E/S mises en mémoire tampon et pas seulement avec les IOCTL.
Erreurs dans les E/S directes IOCTL
Gérez correctement les mémoires tampons de longueur nulle. Pour plus d’informations, consultez Erreurs dans les E/S directes.
Erreurs dans le référencement d’adresses d’espace utilisateur
Validez les pointeurs incorporés dans les demandes d’E/S mises en mémoire tampon. Pour plus d’informations, consultez Erreurs dans le référencement d’adresses User-Space.
Validez n’importe quelle adresse dans l’espace utilisateur avant d’essayer de l’utiliser, à l’aide d’API telles que ProbeForRead et ProbeForWrite le cas échéant.
Lectures et écritures de registre spécifiques au modèle MSR
Les intrinsèques du compilateur, telles que __readmsr et __writemsr , peuvent être utilisées pour accéder aux registres spécifiques au modèle. Si cet accès est requis, le pilote doit toujours case activée que le registre dans lequel lire ou écrire est limité à l’index ou à la plage attendu.
Pour plus d’informations et des exemples de code, consultez Fournir la possibilité de lire/écrire des fichiers MSR dans les meilleures pratiques de sécurité du développement pour les développeurs de pilotes Windows.
Vulnérabilités TOCTOU
Il existe une vulnérabilité de temps de case activée à la durée d’utilisation (TOCTOU) lors de l’utilisation d’E/S directes (pour les IOCTL ou pour la lecture/écriture). N’oubliez pas que le pilote accède à la mémoire tampon de données utilisateur. L’utilisateur peut y accéder simultanément.
Pour gérer ce risque, copiez tous les paramètres qui doivent être validés à partir de la mémoire tampon de données utilisateur vers la mémoire accessible uniquement à partir du mode noyau (par exemple, la pile ou le pool). Ensuite, une fois que les données ne sont pas accessibles par l’application utilisateur, validez et utilisez les données qui ont été transmises.
Le code du pilote doit utiliser correctement la mémoire
Toutes les allocations de pool de pilotes doivent se trouver dans un pool non exécutable (NX). L’utilisation de pools de mémoire NX est par nature plus sécurisée que l’utilisation de pools exécutables non paginés (NP), et offre une meilleure protection contre les attaques par dépassement de capacité.
Les pilotes de périphérique doivent gérer correctement diverses demandes d’E/S en mode utilisateur, ainsi que de noyau à noyau.
Pour permettre aux pilotes de prendre en charge la virtualisation HVCI, il existe des besoins supplémentaires en mémoire. Pour plus d’informations, consultez Implémenter du code compatible HVCI plus loin dans cet article.
Poignées
- Valider les handles passés entre la mémoire en mode utilisateur et en mode noyau. Pour plus d’informations, consultez Gérer la gestion et échec de la validation des handles d’objet.
Objets d’appareil
Sécuriser les objets d’appareil. Pour plus d’informations, consultez Sécurisation des objets d’appareil.
Valider les objets d’appareil. Pour plus d’informations, consultez Échec de la validation des objets d’appareil.
IrPs
WDF et IRPs
L’un des avantages de l’utilisation de WDF est que les pilotes WDF n’accèdent généralement pas directement aux IIP. Par exemple, l’infrastructure convertit les IRP WDM qui représentent des opérations de contrôle d’E/S de lecture, d’écriture et d’appareil en objets de requête d’infrastructure que KMDF/UMDF reçoivent dans les files d’attente d’E/S.
Si vous écrivez un pilote WDM, passez en revue les conseils suivants.
Gérer correctement les mémoires tampons D’E/S IRP
Les articles suivants fournissent des informations sur la validation des valeurs d’entrée IRP :
DispatchReadWrite à l’aide d’E/S mises en mémoire tampon
Erreurs dans les E/S mises en mémoire tampon
DispatchReadWrite à l’aide d’E/S directes
Problèmes de sécurité pour les codes de contrôle d’E/S
Envisagez de valider des valeurs associées à un IRP, telles que les adresses de mémoire tampon et les longueurs.
Si vous avez choisi d’utiliser Ni l’E/S, n’oubliez pas que contrairement à la lecture et à l’écriture, et contrairement aux E/S mises en mémoire tampon et aux E/S directes, lors de l’utilisation de Ni E/S IOCTL, les pointeurs et longueurs de mémoire tampon ne sont pas validés par le gestionnaire d’E/S.
Gérer correctement les opérations d’achèvement IRP
Un pilote ne doit jamais terminer un IRP avec une valeur status de STATUS_SUCCESS, sauf s’il prend en charge et traite réellement l’IRP. Pour plus d’informations sur les méthodes appropriées pour gérer les opérations de saisie semi-automatique, consultez Terminer les irps.
Gérer l’état d’attente IRP du pilote
Le pilote doit marquer l’IRP en attente avant d’enregistrer l’IRP, et doit envisager d’inclure à la fois l’appel à IoMarkIrpPending et l’affectation dans une séquence verrouillée. Pour plus d’informations, consultez Échec de la vérification de l’état d’un pilote et conservation des IRP entrants lorsqu’un appareil est suspendu.
Gérer correctement les opérations d’annulation IRP
Les opérations d’annulation peuvent être difficiles à coder correctement, car elles s’exécutent généralement de manière asynchrone. Les problèmes dans le code qui gère les opérations d’annulation peuvent passer inaperçus pendant longtemps, car ce code n’est généralement pas exécuté fréquemment dans un système en cours d’exécution. Veillez à lire et à comprendre toutes les informations fournies sous Annuler les IRPs. Prêtez une attention particulière à la synchronisation de l’annulation D’IRP et aux points à prendre en compte lors de l’annulation des IRPs.
L’un des moyens recommandés pour réduire les problèmes de synchronisation associés aux opérations d’annulation consiste à implémenter une file d’attente IRP d’annulation sécurisée.
Gérer correctement les opérations de nettoyage et de fermeture IRP
Veillez à comprendre la différence entre les demandes IRP_MJ_CLEANUP et IRP_MJ_CLOSE . Les demandes de nettoyage arrivent après qu’une application ferme tous les handles sur un objet de fichier, mais parfois avant la fin de toutes les demandes d’E/S. Les demandes de fermeture arrivent une fois que toutes les demandes d’E/S pour l’objet de fichier ont été terminées ou annulées. Pour plus d’informations, consultez les articles suivants :
DispatchCreate, DispatchClose et DispatchCreateClose Routines
Erreurs dans la gestion des opérations de nettoyage et de fermeture
Pour plus d’informations sur la gestion correcte des IRPs, consultez Erreurs supplémentaires dans la gestion des IRPs.
Autres problèmes de sécurité
Utilisez un verrou ou une séquence verrouillée pour empêcher les conditions de course. Pour plus d’informations, consultez Erreurs dans un environnement multiprocesseur.
Assurez-vous que les pilotes de périphérique gèrent correctement les différentes demandes d’E/S en mode utilisateur et de noyau à noyau.
Assurez-vous qu’aucun filtre TDI ou LSP n’est installé par le pilote ou les packages logiciels associés pendant l’installation ou l’utilisation.
Utiliser des fonctions sécurisées
Utilisez des fonctions de chaîne sécurisée. Pour plus d’informations, consultez Utilisation de fonctions de chaîne sécurisée.
Utilisez des fonctions arithmétiques sécurisées. Pour plus d’informations, consultez Routines de bibliothèque d’entiers sécurisés
Utilisez des fonctions de conversion sécurisées.
Vulnérabilités de code supplémentaires
En plus des vulnérabilités possibles abordées ici, cet article fournit des informations supplémentaires sur l’amélioration de la sécurité du code du pilote en mode noyau : Création de pilotes Kernel-Mode fiables.
Pour plus d’informations sur le codage sécurisé C et C++, consultez Ressources de codage sécurisées à la fin de cet article.
Gérer le contrôle d’accès aux pilotes
Élément de la liste de contrôle de sécurité 7 :Passez en revue votre pilote pour vous assurer que vous contrôlez correctement l’accès.
Gestion du contrôle d’accès aux pilotes - WDF
Les pilotes doivent fonctionner pour empêcher les utilisateurs d’accéder de manière inappropriée aux appareils et fichiers d’un ordinateur. Pour empêcher l’accès non autorisé aux appareils et aux fichiers, vous devez :
Nommez les objets d’appareil uniquement si nécessaire. Les objets d’appareil nommés ne sont généralement nécessaires que pour des raisons héritées, par exemple si vous avez une application qui s’attend à ouvrir l’appareil à l’aide d’un nom particulier ou si vous utilisez un appareil/un appareil de contrôle non PNP. Notez que les pilotes WDF n’ont pas besoin de nommer leur FDO de périphérique PnP pour créer un lien symbolique à l’aide de WdfDeviceCreateSymbolicLink.
Sécuriser l’accès aux interfaces et objets d’appareil.
Pour permettre aux applications ou à d’autres pilotes WDF d’accéder à votre PDO de périphérique PnP, vous devez utiliser des interfaces d’appareil. Pour plus d’informations, consultez Utilisation d’interfaces d’appareil. Une interface d’appareil sert de lien symbolique à l’AOP de votre pile d’appareils.
L’un des meilleurs moyens de contrôler l’accès à l’AOP consiste à spécifier une chaîne SDDL dans votre inf. Si la chaîne SDDL ne figure pas dans le fichier INF, Windows applique un descripteur de sécurité par défaut. Pour plus d’informations, consultez Sécurisation des objets d’appareil et SDDL pour les objets d’appareil.
Pour plus d’informations sur le contrôle de l’accès, consultez les articles suivants :
Contrôle de l’accès des appareils dans les pilotes KMDF
Noms, descripteurs de sécurité et classes d’appareils - Rendre les objets d’appareil accessibles... et SAFE de janvier février 2017 The NT Insider Newsletter publié par OSR.
Gestion du contrôle d’accès aux pilotes - WDM
Si vous utilisez un pilote WDM et que vous avez utilisé un objet d’appareil nommé, vous pouvez utiliser IoCreateDeviceSecure et spécifier un SDDL pour le sécuriser. Lorsque vous implémentez IoCreateDeviceSecure , spécifiez toujours un GUID de classe personnalisé pour DeviceClassGuid. Vous ne devez pas spécifier un GUID de classe existant ici. Cela risque d’interrompre les paramètres de sécurité ou la compatibilité pour d’autres appareils appartenant à cette classe. Pour plus d’informations, consultez WdmlibIoCreateDeviceSecure.
Pour plus d’informations, consultez les articles suivants :
Contrôle de l’accès aux appareils
Contrôle de l’accès à l’espace de noms d’appareil
Modèle de sécurité Windows pour les développeurs de pilotes
Hiérarchie des risques des identificateurs de sécurité (SID)
La section suivante décrit la hiérarchie des risques des SID courants utilisés dans le code du pilote. Pour obtenir des informations générales sur SDDL, consultez SDDL for Device Objects, SID Strings et SDDL String Syntax.
Il est important de comprendre que si les appelants à privilèges inférieurs sont autorisés à accéder au noyau, le risque de code est accru. Dans ce diagramme récapitulatif, le risque augmente à mesure que vous autorisez l’accès des SID à privilèges inférieurs à vos fonctionnalités de pilote.
SY (System)
\/
BA (Built-in Administrators)
\/
LS (Local Service)
\/
BU (Built-in User)
\/
AC (Application Container)
En suivant le principe général de sécurité des privilèges minimum, configurez uniquement le niveau d’accès minimal requis pour que votre pilote fonctionne.
Contrôle de sécurité IOCTL précis WDM
Pour mieux gérer la sécurité lorsque des IOCTL sont envoyés par des appelants en mode utilisateur, le code du pilote peut inclure la fonction IoValidateDeviceIoControlAccess . Cette fonction permet à un pilote de case activée droits d’accès. Lors de la réception d’un IOCTL, un pilote peut appeler IoValidateDeviceIoControlAccess, en spécifiant FILE_READ_ACCESS, FILE_WRITE_ACCESS ou les deux.
L’implémentation d’un contrôle de sécurité IOCTL granulaire ne remplace pas la nécessité de gérer l’accès aux pilotes à l’aide des techniques décrites ci-dessus.
Pour plus d’informations, consultez les articles suivants :
Définition de codes de contrôle d’E/S
Implémenter du code compatible HVCI
Élément de liste de contrôle de sécurité #8 :Vérifiez que votre pilote utilise la mémoire pour qu’il soit compatible avec HVCI.
Utilisation de la mémoire et compatibilité HVCI
HVCI utilise la technologie matérielle et la virtualisation pour isoler la fonction de prise de décision d’intégrité du code (CI) du reste du système d’exploitation. Lorsque vous utilisez la sécurité basée sur la virtualisation pour isoler CI, la seule façon dont la mémoire du noyau peut devenir exécutable consiste à effectuer une vérification CI. Cela signifie que les pages de mémoire du noyau ne peuvent jamais être accessibles en écriture et exécutables (W+X) et que le code exécutable ne peut pas être modifié directement.
Pour implémenter du code compatible HVCI, vérifiez que votre code de pilote effectue les opérations suivantes :
- Opte pour NX par défaut
- Utilise des API/indicateurs NX pour l’allocation de mémoire (NonPagedPoolNx)
- N’utilise pas de sections qui sont à la fois accessibles en écriture et exécutables
- Ne tente pas de modifier directement la mémoire système exécutable
- N’utilise pas de code dynamique dans le noyau
- Ne charge pas les fichiers de données comme exécutables
- L’alignement de section est un multiple de 0x1000 (PAGE_SIZE). Par exemple, DRIVER_ALIGNMENT=0x1000
Pour plus d’informations sur l’utilisation de l’outil et une liste d’appels de mémoire incompatibles, consultez Implémenter du code compatible HVCI.
Pour plus d’informations sur le test de sécurité de base du système associé, consultez Test de préparation à l’intégrité du code hyperviseur et Intégrité du code protégé par l’hyperviseur (HVCI).
Suivre les meilleures pratiques de code spécifiques à la technologie
Élément de liste de contrôle de sécurité n° 9 :Passez en revue les conseils technologiques suivants pour votre pilote.
Systèmes de fichiers
Pour plus d’informations, consultez les articles suivants sur la sécurité des pilotes de système de fichiers :
Présentation de la sécurité des systèmes de fichiers
Problèmes de sécurité du système de fichiers
Fonctionnalités de sécurité pour les systèmes de fichiers
Coexistence avec d’autres pilotes de filtre de système de fichiers
NDIS - Mise en réseau
Pour plus d’informations sur la sécurité des pilotes NDIS, consultez Problèmes de sécurité pour les pilotes réseau.
Affichage
Pour plus d’informations sur la sécurité des pilotes d’affichage, consultez <Contenu en attente>.
Imprimantes
Pour plus d’informations sur la sécurité des pilotes d’imprimante, consultez Considérations relatives à la sécurité du pilote d’imprimante V4.
Problèmes de sécurité pour les pilotes d’acquisition d’images Windows (WIA)
Pour plus d’informations sur la sécurité WIA, consultez Problèmes de sécurité pour les pilotes d’acquisition d’images Windows (WIA).
Améliorer la sécurité de l’installation de l’appareil
Élément de liste de contrôle de sécurité #10 :Passez en revue les conseils de création et d’installation du pilote inf pour vous assurer que vous suivez les meilleures pratiques.
Lorsque vous créez le code qui installe votre pilote, vous devez vous assurer que l’installation de votre appareil sera toujours effectuée de manière sécurisée. Une installation d’appareil sécurisée est une installation qui effectue les opérations suivantes :
- Limite l’accès à l’appareil et à ses classes d’interface d’appareil
- Limite l’accès aux services de pilote qui ont été créés pour l’appareil
- Protège les fichiers de pilotes contre toute modification ou suppression
- Limite l’accès aux entrées de Registre de l’appareil
- Limite l’accès aux classes WMI de l’appareil
- Utilise correctement les fonctions SetupAPI
Pour plus d’informations, consultez les articles suivants :
Création d’installations d’appareils sécurisées
Instructions relatives à l’utilisation de SetupAPI
Utilisation des fonctions d’installation d’appareil
Rubriques avancées sur l’installation des périphériques et des pilotes
Effectuer une révision du code d’homologue
Élément de la liste de contrôle de sécurité n° 11 :Effectuer une révision du code d’homologue pour rechercher les problèmes non exposés par les autres outils et processus
Recherchez des réviseurs de code compétents pour rechercher les problèmes que vous avez peut-être manqués. Un deuxième ensemble d’yeux verra souvent des problèmes que vous avez peut-être négligés.
Si vous n’avez pas le personnel approprié pour examiner votre code en interne, envisagez de faire appel à une aide externe à cet effet.
Exécuter une signature de pilote de mise en production appropriée
Élément de la liste de contrôle de sécurité n° 12 :Utilisez le portail partenaire Windows pour signer correctement votre pilote pour la distribution.
Avant de publier un package de pilotes au public, nous vous recommandons de soumettre le package pour certification. Pour plus d’informations, consultez Test des performances et de la compatibilité, Prise en main du programme Matériel, Services de tableau de bord matériel et Attestation de signature d’un pilote de noyau pour la mise en production publique.
Utiliser l’analyse du code dans Visual Studio pour examiner la sécurité des pilotes
Élément de la liste de contrôle de sécurité n° 13 :Suivez ces étapes pour utiliser la fonctionnalité d’analyse du code dans Visual Studio pour case activée des vulnérabilités dans votre code de pilote.
Utilisez la fonctionnalité d’analyse du code dans Visual Studio pour case activée des failles de sécurité dans votre code. Le Kit de pilotes Windows (WDK) installe des ensembles de règles conçus pour case activée pour les problèmes dans le code de pilote natif.
Pour plus d’informations, consultez Comment exécuter l’analyse du code pour les pilotes.
Pour plus d’informations, consultez Vue d’ensemble de l’analyse du code pour les pilotes. Pour plus d’informations sur l’analyse du code, consultez Visual Studio 2013 analyse statique du code en détail.
Pour vous familiariser avec l’analyse du code, vous pouvez utiliser l’un des exemples de pilotes, par exemple, l’exemple de grille-pain proposé ou https://github.com/Microsoft/Windows-driver-samples/tree/main/general/toaster/toastDrv/kmdf/func/featured l’exemple https://github.com/Microsoft/Windows-driver-samples/tree/main/security/elamELAM Early Launch Anti-Malware.
Ouvrez la solution de pilote dans Visual Studio.
Dans Visual Studio, pour chaque projet de la solution, modifiez les propriétés du projet pour utiliser l’ensemble de règles souhaité. Par exemple : Propriétés >> du projet >> Analyse >> du code Général, sélectionnez Règles de pilote recommandées. En plus d’utiliser les règles de pilote recommencées, utilisez l’ensemble de règles natives recommandées .
Sélectionnez Générer >> Exécuter l’analyse du code sur la solution.
Affichez les avertissements sous l’onglet Liste d’erreurs de la fenêtre de sortie de build dans Visual Studio.
Sélectionnez la description de chaque avertissement pour voir la zone problématique dans votre code.
Sélectionnez le code d’avertissement lié pour afficher des informations supplémentaires.
Déterminez si votre code doit être modifié ou si une annotation doit être ajoutée pour permettre au moteur d’analyse du code de suivre correctement l’intention de votre code. Pour plus d’informations sur l’annotation de code, consultez Utilisation d’annotations SAL pour réduire les défauts de code C/C++ et Annotations SAL 2.0 pour les pilotes Windows.
Pour obtenir des informations générales sur sal, reportez-vous à cet article disponible sur OSR. https://www.osr.com/blog/2015/02/23/sal-annotations-dont-hate-im-beautiful/
Utiliser le vérificateur de pilote statique pour case activée des vulnérabilités
Élément de la liste de contrôle de sécurité n° 14 :Suivez ces étapes pour utiliser le vérificateur de pilote statique (SDV) dans Visual Studio pour case activée des vulnérabilités dans votre code de pilote.
Static Driver Verifier (SDV) utilise un ensemble de règles d’interface et un modèle du système d’exploitation pour déterminer si le pilote interagit correctement avec le système d’exploitation Windows. SDV détecte des défauts dans le code du pilote qui pourraient pointer vers des bogues potentiels dans les pilotes.
Pour plus d’informations, consultez Présentation du vérificateur de pilote statique et du vérificateur de pilote statique.
Notez que seuls certains types de pilotes sont pris en charge par SDV. Pour plus d’informations sur les pilotes que SDV peut vérifier, consultez Pilotes pris en charge. Reportez-vous aux pages suivantes pour plus d’informations sur les tests SDV disponibles pour le type de pilote que vous utilisez.
- Règles pour les pilotes WDM
- Règles pour les pilotes KMDF
- Règles pour les pilotes NDIS
- Règles pour les pilotes Storport
- Règles pour les pilotes audio
- Règles pour les pilotes AVStream
Pour vous familiariser avec SDV, vous pouvez utiliser l’un des exemples de pilotes (par exemple, l’exemple de grille-pain proposé : https://github.com/Microsoft/Windows-driver-samples/tree/main/general/toaster/toastDrv/kmdf/func/featured).
Ouvrez la solution de pilote ciblé dans Visual Studio.
Dans Visual Studio, remplacez le type de build par Release. Static Driver Verifier nécessite que le type de build soit release, et non debug.
Dans Visual Studio, sélectionnez Générer une >> solution de génération.
Dans Visual Studio, sélectionnez Pilote >> Launch Static Driver Verifier.
Dans SDV, sous l’onglet Règles , sélectionnez Par défaut sous Ensembles de règles.
Bien que les règles par défaut rencontrent de nombreux problèmes courants, envisagez également d’exécuter l’ensemble de règles De tous les pilotes plus complet.
Sous l’onglet Principal de SDV, sélectionnez Démarrer.
Une fois SDV terminé, passez en revue les avertissements dans la sortie. L’onglet Principal affiche le nombre total de défauts détectés.
Sélectionnez chaque avertissement pour charger la page de rapport SDV et examinez les informations associées à la vulnérabilité de code possible. Utilisez le rapport pour examiner le résultat de la vérification et identifier les chemins d’accès dans votre pilote qui échouent à une vérification SDV. Pour plus d’informations, consultez Rapport du vérificateur de pilote statique.
Vérifier le code avec l’analyseur binaire BinSkim
Élément de la liste de contrôle de sécurité n° 15 :Suivez ces étapes pour utiliser BinSkim afin de doubler case activée que les options de compilation et de génération sont configurées pour réduire les problèmes de sécurité connus.
Utilisez BinSkim pour examiner les fichiers binaires afin d’identifier les pratiques de codage et de création qui peuvent potentiellement rendre le fichier binaire vulnérable.
BinSkim recherche :
- Utilisation d’ensembles d’outils de compilateur obsolètes : les fichiers binaires doivent être compilés par rapport aux ensembles d’outils de compilateur les plus récents dans la mesure du possible pour optimiser l’utilisation des atténuations de sécurité actuelles au niveau du compilateur et du système d’exploitation.
- Paramètres de compilation non sécurisés : les fichiers binaires doivent être compilés avec les paramètres les plus sécurisés possibles pour activer les atténuations de sécurité fournies par le système d’exploitation, optimiser les erreurs du compilateur et les rapports d’avertissements actionnables, entre autres choses.
- Problèmes de signature : les fichiers binaires signés doivent être signés avec des algorithmes forts sur le plan du chiffrement.
BinSkim est un outil open source qui génère des fichiers de sortie qui utilisent le format SARIF (Static Analysis Results Interchange Format). BinSkim remplace l’ancien outil BinScope .
Pour plus d’informations sur BinSkim, consultez le Guide de l’utilisateur BinSkim.
Suivez ces étapes pour vérifier que les options de compilation de sécurité sont correctement configurées dans le code que vous expédiez.
Téléchargez et installez le SDK .NET Core multiplateforme.
Vérifiez que Visual Studio est installé. Pour plus d’informations sur le téléchargement et l’installation de Visual Studio, consultez Installer Visual Studio.
Il existe plusieurs options pour télécharger BinSkim, comme un package NuGet. Dans cet exemple, nous allons utiliser l’option git clone pour télécharger à partir d’ici : https://github.com/microsoft/binskim et l’installer sur un PC Windows 64 bits.
Ouvrez une fenêtre d’invite de commandes développeur Visual Studio et créez un répertoire, par exemple
C:\binskim-master.C:\> Md \binskim-masterAccédez au répertoire que vous venez de créer.
C:\> Cd \binskim-masterUtilisez la commande git clone pour télécharger tous les fichiers nécessaires.
C:\binskim-master> git clone --recurse-submodules https://github.com/microsoft/binskim.gitAccédez au nouveau
binskimdirctory créé par la commande clone.C:\> Cd \binskim-master\binskimExécutez BuildAndTest.cmd pour vous assurer que la build de mise en production réussit et que tous les tests réussissent.
C:\binskim-master\binskim> BuildAndTest.cmd Welcome to .NET Core 3.1! --------------------- SDK Version: 3.1.101 ... C:\binskim-master\binskim\bld\bin\AnyCPU_Release\Publish\netcoreapp2.0\win-x64\BinSkim.Sdk.dll 1 File(s) copied C:\binskim-master\binskim\bld\bin\AnyCPU_Release\Publish\netcoreapp2.0\linux-x64\BinSkim.Sdk.dll 1 File(s) copied ...Le processus de génération crée un ensemble de répertoires avec les exécutables BinSkim. Accédez au répertoire de sortie de build win-x64.
C:\binskim-master\binskim> Cd \binskim-master\bld\bin\AnyCPU_Release\Publish\netcoreapp2.0\win-x64>Afficher l’aide pour l’option Analyser.
C:\binskim-master\binskim\bld\bin\AnyCPU_Release\Publish\netcoreapp2.0\win-x64> BinSkim help analyze
BinSkim PE/MSIL Analysis Driver 1.6.0.0
--sympath Symbols path value, e.g., SRV*http://msdl.microsoft.com/download/symbols or Cache*d:\symbols;Srv*http://symweb. See
https://learn.microsoft.com/windows-hardware/drivers/debugger/advanced-symsrv-use for syntax information. Note that BinSkim will clear the
_NT_SYMBOL_PATH environment variable at runtime. Use this argument for symbol information instead.
--local-symbol-directories A set of semicolon-delimited local directory paths that will be examined when attempting to locate PDBs.
-o, --output File path to which analysis output will be written.
--verbose Emit verbose output. The resulting comprehensive report is designed to provide appropriate evidence for compliance scenarios.
...
Définition du chemin du symbole
Si vous générez tout le code que vous analysez sur la même machine sur laquelle vous exécutez BinSkim, vous n’avez généralement pas besoin de définir le chemin du symbole. En effet, vos fichiers de symboles sont disponibles dans la zone locale dans laquelle vous avez compilé. Si vous utilisez un système de génération plus complexe ou redirigez vos symboles vers un autre emplacement (et non en même temps que le fichier binaire compilé), utilisez --local-symbol-directories pour ajouter ces emplacements à la recherche de fichier de symboles.
Si votre code fait référence à un fichier binaire compilé qui ne fait pas partie de votre code, la sympathie du débogueur Windows peut être utilisée pour récupérer des symboles afin de vérifier la sécurité de ces dépendances de code. Si vous rencontrez un problème dans ces dépendances, vous ne pourrez peut-être pas les résoudre. Mais il peut être utile d’être conscient de tout risque de sécurité que vous acceptez en prenant ces dépendances.
Conseil
Lors de l’ajout d’un chemin de symbole (qui fait référence à un serveur de symboles en réseau), ajoutez un emplacement de cache local pour spécifier un chemin d’accès local pour mettre en cache les symboles. Ne pas faire cela peut considérablement compromettre les performances de BinSkim. L’exemple suivant spécifie un cache local à l’emplacement d :\symbols.
--sympath Cache*d:\symbols;Srv*http://symweb Pour plus d’informations sur la sympathie, consultez Chemin des symboles pour les débogueurs Windows.
Exécutez la commande suivante pour analyser un fichier binaire de pilote compilé. Mettez à jour le chemin d’accès cible pour qu’il pointe vers votre fichier de .sys de pilote conforme.
C:\binskim-master\binskim\bld\bin\AnyCPU_Release\Publish\netcoreapp2.0\win-x64> BinSkim analyze "C:\Samples\KMDF_Echo_Driver\echo.sys"Pour plus d’informations, ajoutez l’option détaillée comme ceci.
C:\binskim-master\binskim\bld\bin\AnyCPU_Release\Publish\netcoreapp2.0\win-x64> BinSkim analyze "C:\Samples\KMDF_Echo_Driver\osrusbfx2.sys" --verboseNotes
L’option --verbose génère des résultats de réussite/échec explicites pour chaque case activée. Si vous ne fournissez pas de commentaires, vous ne verrez que les défauts détectés par BinSkim. L’option --verbose n’est généralement pas recommandée pour les systèmes d’automatisation réels en raison de la taille accrue des fichiers journaux et parce qu’elle rend plus difficile la détection des défaillances individuelles lorsqu’elles se produisent, car elles seront incorporées au milieu d’un grand nombre de résultats de réussite.
Passez en revue la sortie de la commande pour rechercher les problèmes possibles. Cet exemple de sortie montre trois tests qui ont réussi. Des informations supplémentaires sur les règles, telles que BA2002, sont disponibles dans le Guide de l’utilisateur BinSkim.
Analyzing... Analyzing 'osrusbfx2.sys'... ... C:\Samples\KMDF_Echo_Driver\osrusbfx2.sys\Debug\osrusbfx2.sys: pass BA2002: 'osrusbfx2.sys' does not incorporate any known vulnerable dependencies, as configured by current policy. C:\Samples\KMDF_Echo_Driver\Debug\osrusbfx2.sys: pass BA2005: 'osrusbfx2.sys' is not known to be an obsolete binary that is vulnerable to one or more security problems. C:\Samples\KMDF_Echo_Driver\osrusbfx2.sys: pass BA2006: All linked modules of 'osrusbfx2.sys' generated by the Microsoft front-end satisfy configured policy (compiler minimum version 17.0.65501.17013).Cette sortie indique que le test BA3001 n’est pas exécuté, car l’outil indique que le pilote n’est pas un binaire ELF.
... C:\Samples\KMDF_Echo_Driver\Debug\osrusbfx2.sys: notapplicable BA3001: 'osrusbfx2.sys' was not evaluated for check 'EnablePositionIndependentExecutable' as the analysis is not relevant based on observed metadata: image is not an ELF binary.Cette sortie montre une erreur pour le test BA2007.
... C:\Samples\KMDF_Echo_Driver\Debug\osrusbfx2.sys: error BA2007: 'osrusbfx2.sys' disables compiler warning(s) which are required by policy. A compiler warning is typically required if it has a high likelihood of flagging memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, enable the indicated warning(s) by removing /Wxxxx switches (where xxxx is a warning id indicated here) from your command line, and resolve any warnings subsequently raised during compilation.
Pour activer ces avertissements dans Visual Studio, sous C/C++ dans les pages de propriétés du projet, supprimez les valeurs que vous ne souhaitez pas exclure dans Désactiver les avertissements spécifiques.
Les options de compilation par défaut dans Visual Studio pour les projets de pilotes peuvent désactiver les avertissements tels que les suivants. Ces avertissements seront signalés par BinSkim.
C4627 - 'description' : ignoré lors de la recherche d’une utilisation d’en-tête précompilée
C4986 - 'declaration' : la spécification d’exception ne correspond pas à la déclaration précédente
Pour plus d’informations sur les avertissements du compilateur, consultez Avertissements du compilateur par version du compilateur.
Utiliser des outils de validation de code supplémentaires
Élément de liste de contrôle de sécurité #16 :utilisez ces outils supplémentaires pour vérifier que votre code suit les recommandations de sécurité et pour rechercher les lacunes qui ont été manquées dans votre processus de développement.
En plus de l’analyse visual Studio Code, du vérificateur de pilote statique et de Binskim abordés ci-dessus, utilisez les outils suivants pour rechercher les lacunes qui ont été manquées dans votre processus de développement.
Driver Verifier
Driver Verifier permet de tester en direct le pilote. Driver Verifier analyse les pilotes en mode noyau Windows et les pilotes graphiques pour détecter les appels ou actions de fonction non autorisés susceptibles d’endommager le système. Driver Verifier peut soumettre les pilotes Windows à divers stress et tests pour trouver un comportement incorrect. Pour plus d’informations, consultez Type de débogage.
Tests du programme de compatibilité matérielle
Le programme de compatibilité matérielle inclut des tests liés à la sécurité qui peuvent être utilisés pour rechercher les vulnérabilités du code. Le programme de compatibilité matérielle Windows tire parti des tests du Kit de laboratoire matériel Windows (HLK). Les tests HLK Device Fundamentals peuvent être utilisés sur la ligne de commande pour exercer le code du pilote et rechercher des faiblesses. Pour obtenir des informations générales sur les tests de base de l’appareil et le programme de compatibilité matérielle, consultez Windows Hardware Lab Kit.
Les tests suivants sont des exemples de tests qui peuvent être utiles pour case activée code de pilote pour certains comportements associés aux vulnérabilités du code :
DF - Test IOCTL aléatoire Fuzz (Fiabilité)
DF - Test de sous-ouverture fuzz (fiabilité)
DF - Test FSCTL fuzz zero length (Fiabilité)
DF - Test FSCTL aléatoire Fuzz (Fiabilité)
DF - Test de l’API Fuz Misc (Fiabilité)
Vous pouvez également utiliser le fuzzing du retard de synchronisation du noyau qui est inclus dans Driver Verifier.
Les tests CHAOS (Simultané Hardware and Operating System) exécutent simultanément divers tests de pilotes PnP, tests fuzz du pilote de périphérique et tests du système d’alimentation. Pour plus d’informations, consultez Tests CHAOS (Principes de base de l’appareil).
Les tests d’intrusion De base de l’appareil effectuent différentes formes d’attaques d’entrée, qui sont un composant essentiel des tests de sécurité. Les tests d’attaque et de pénétration peuvent aider à identifier les vulnérabilités dans les interfaces logicielles. Pour plus d’informations, consultez Tests d’intrusion (principes de base de l’appareil).
Utilisez device Guard - Test de conformité, ainsi que les autres outils décrits dans cet article, pour vérifier que votre pilote est compatible avec HVCI.
Outils de test personnalisés et spécifiques au domaine
Envisagez le développement de tests de sécurité personnalisés spécifiques à un domaine. Pour développer des tests supplémentaires, rassemblez les commentaires des concepteurs originaux du logiciel, ainsi que des ressources de développement non liées familiarisées avec le type spécifique de pilote en cours de développement, et une ou plusieurs personnes familiarisées avec l’analyse et la prévention des intrusions de sécurité.
Passer en revue les techniques et extensions du débogueur
Élément de liste de contrôle de sécurité #17 :Passez en revue ces outils de débogueur et envisagez leur utilisation dans votre workflow de débogage de développement.
Commandes de débogueur liées à la sécurité
L’extension !acl met en forme et affiche le contenu d’une liste de contrôle d’accès (ACL). Pour plus d’informations, consultez Détermination de l’ACL d’un objet et !acl.
L’extension !token affiche une vue mise en forme d’un objet de jeton de sécurité. Pour plus d’informations, consultez !token.
L’extension !tokenfields affiche les noms et les décalages des champs dans l’objet de jeton d’accès (la structure TOKEN). Pour plus d’informations, consultez !tokenfields.
L’extension !sid affiche l’identificateur de sécurité (SID) à l’adresse spécifiée. Pour plus d’informations, consultez !sid.
L’extension !sd affiche le descripteur de sécurité à l’adresse spécifiée. Pour plus d’informations, consultez !sd.
Centre de création de rapports sur les pilotes vulnérables et malveillants Microsoft
Tout le monde peut envoyer un pilote douteux à l’aide du Centre de création de rapports sur les pilotes vulnérables et malveillants Microsoft. Reportez-vous à cette entrée de blog pour plus d’informations sur la façon dont les pilotes sont soumis pour analyse - Améliorer la sécurité du noyau avec le nouveau Centre de création de rapports sur les pilotes vulnérables et malveillants Microsoft
Le Centre de rapports peut analyser et analyser les pilotes Windows créés pour les architectures x86 et x64. Les pilotes analysés vulnérables et malveillants sont signalés pour analyse et investigation par l’équipe de pilotes vulnérables de Microsoft. Une fois que les pilotes vulernables sont confirmés, une notification appropriée se produit, ils sont ajoutés à la liste de blocage des pilotes vulnérables. Pour plus d’informations à ce sujet, consultez Règles de blocage de pilotes recommandées par Microsoft. Ces règles sont appliquées par défaut aux appareils HVCI (Hypervisor-protected code integrity) et Windows 10 en mode S.
Passer en revue les ressources de codage sécurisé
Élément de la liste de contrôle de sécurité n° 18 :Passez en revue ces ressources pour approfondir votre compréhension des meilleures pratiques de codage sécurisé applicables aux développeurs de pilotes.
Passez en revue ces ressources pour en savoir plus sur la sécurité des pilotes
Instructions de codage de pilote en mode noyau sécurisé
Création de pilotes Kernel-Mode fiables
Sécuriser les organisations de codage
Carnegie Mellon University SEI CERT
Carnegie Mellon University SEI CERT C Coding Standard : Rules for Developing Safe, Reliable, and Secure Systems (Édition 2016).
MITRE - Faiblesses traitées par le CERT C Secure Coding Standard
Building Security In Maturity Model (BSIMM) - https://www.bsimm.com/
SAFECode - https://safecode.org/
OSR
OSR fournit des services de formation et de conseil en développement de pilotes. Ces articles de la newsletter OSR mettent en évidence les problèmes de sécurité des pilotes.
Vous avez utilisé la protection - À l’intérieur du pilote & sécurité de l’appareil
Verrouillage des pilotes - Une enquête sur les techniques
Meltdown et Spectre : Qu’en est-il des pilotes ?
Étude de cas
Livres
24 péchés mortels de la sécurité logicielle : les défauts de programmation et la façon de les résoudre par Michael Howard, David LeBlanc et John Viega
L’art de l’évaluation de la sécurité logicielle : identifier et prévenir les vulnérabilités logicielles, Mark Dowd, John McDonald et Justin Schuh
Écriture de Secure Software Second Edition, Michael Howard et David LeBlanc
L’art de l’évaluation de la sécurité logicielle : identifier et prévenir les vulnérabilités logicielles, Mark Dowd et John McDonald
Codage sécurisé en C et C++ (série SEI en ingénierie logicielle) 2e édition, Robert C. Seacord
Programmation du modèle pilote Microsoft Windows (2e édition), Walter Oney
Développement de pilotes avec Windows Driver Foundation (référence des développeurs), Penny Orwick et Guy Smith
Entrainement
La formation en classe des pilotes Windows est disponible auprès de fournisseurs tels que les suivants :
La formation en ligne sur le codage sécurisé est disponible à partir de diverses sources. Par exemple, ce cours est disponible à partir de coursera sur :
Identification des vulnérabilités de sécurité dans la programmation C/C++.
SAFECode offre également une formation gratuite :
Certification professionnelle
CERT offre une certification professionnelle de codage sécurisé.
Résumé des principaux points à retenir
La sécurité des pilotes est une entreprise complexe qui contient de nombreux éléments, mais voici quelques points clés à prendre en compte :
Les pilotes vivent dans le noyau Windows, et le fait de rencontrer un problème lors de l’exécution dans le noyau expose l’ensemble du système d’exploitation. Pour cette raison, prêtez une attention particulière à la sécurité et à la conception des pilotes en tenant compte de la sécurité.
Appliquez le principe des privilèges minimum :
a. Utiliser une chaîne SDDL stricte pour restreindre l’accès au pilote
b. Restreindre davantage les IOCTL individuels
Créez un modèle de menace pour identifier les vecteurs d’attaque et déterminez si quelque chose peut être restreint davantage.
Veillez à ce que les pointeurs incorporés soient transmis à partir du mode utilisateur. Elles doivent être sondées, accessibles dans try sauf, et elles sont sujettes aux problèmes de temps de case activée utilisation (ToCToU), sauf si la valeur de la mémoire tampon est capturée et comparée.
Si vous n’êtes pas sûr, utilisez METHOD_BUFFERED comme méthode de mise en mémoire tampon IOCTL.
Utilisez les utilitaires d’analyse du code pour rechercher les vulnérabilités de code connues et corriger les problèmes identifiés.
Recherchez des réviseurs de code compétents pour rechercher les problèmes que vous avez peut-être manqués.
Utilisez des vérificateurs de pilotes et testez votre pilote avec plusieurs entrées, y compris les cas d’angle.
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour