Administration Windows

Dans le noyau de Windows Vista : 3è partie

Mark Russinovich

 

Vue d'ensemble:

• Fiabilité
• Récupération
• Sécurité

Cette série a couvert jusqu'à présent les améliorations du noyau de Windows Vista liées aux processus, à l'E/S, à la gestion de la mémoire, au démarrage et à l'arrêt du système, ainsi qu'à la gestion de l'alimentation. Dans ce troisième et dernier

numéro, je jette un coup d'œil sur les fonctionnalités et les améliorations concernant la fiabilité, la récupération et la sécurité.

L'une des fonctionnalités que je n'aborde pas dans cette série est le Contrôle du compte utilisateur (UAC), qui se compose de plusieurs technologies différentes, y compris la virtualisation des systèmes et registres de fichiers pour les applications héritées, le consentement d'élévation pour accéder aux droits administratifs et le mécanisme Windows® Integrity Level isolant les processus fonctionnant avec les droits administratifs provenant des processus moins privilégiés s'exécutant dans le même compte. Vous pourrez consulter mon analyse approfondie du fonctionnement interne de l'UAC dans une prochaine édition de Technet Magazine.

Windows Vista™ améliore la fiabilité de votre système et votre capacité à diagnostiquer les problèmes relatifs aux systèmes et aux applications via plusieurs nouvelles fonctionnalités et améliorations. Par exemple, le Suivi d'évènements du noyau de l'enregistreur Windows (ETW) est toujours actif, générant des évènements de suivi pour les fichiers, les registres, les interruptions et autres types d'activités dans un tampon circulaire. Lorsqu'un problème survient, la nouvelle Windows Diagnostic Infrastructure (WDI) peut capturer un cliché du tampon et l'analyser localement ou l'envoyer au service d'assistance de Microsoft pour obtenir un dépannage.

Le nouveau moniteur de performances et de fiabilité Windows aide les utilisateurs à relier les erreurs, telles que les incidents et les blocages, aux changements qui ont été apportés à la configuration du système. Le puissant SRT (System Repair Tool) remplace la Console de récupération pour les récupérations hors ligne des systèmes qui ne peuvent pas redémarrer.

Il existe trois domaines qui s'appuient sur les changements du système au niveau du noyau, ce qui mérite une analyse plus précise dans cet article : Le Gestionnaire de transactions du noyau (KTM), le traitement amélioré des incidents et les Versions précédentes.

Gestionnaire de transactions du noyau

L'un des aspects les plus ennuyeux du développement de logiciels consiste en la gestion des conditions d'erreur. Ceci est particulièrement vrai si, lors de la réalisation d'une opération de haut niveau, une application a terminé une ou plusieurs sous-tâches, entraînant des modifications au système ou au registre de fichiers. Par exemple, un service de mise à jour des logiciels d'une application donnée peut effectuer plusieurs mises à jour du registre, remplacer l'un des exécutables de cette application, puis se voir refuser l'accès lorsqu'il tente de mettre à jour un second exécutable. Si ce service ne veut pas quitter l'application dans cet état incohérent, il doit suivre tous les changements qu'il apporte et être prêt à les annuler. Il est difficile de tester le code de récupération des erreurs et cette opération est donc souvent ignorée. Ainsi, en cas d'erreur au niveau du code de récupération, ces manœuvres peuvent s'avérer inefficaces.

Les applications écrites pour Windows Vista peuvent, avec très peu d'efforts, générer des capacités automatiques de récupération des erreurs à l'aide de la nouvelle prise en charge transactionnelle NTFS et du registre du Gestionnaire de transactions du noyau. Lorsqu'une application souhaite effectuer plusieurs modifications apparentées, elle peut soit créer une transaction avec le Coordinateur de transactions réparties (DTC) et une gestion transactionnelle KTM, soit directement créer une gestion KTM et associer les modifications des fichiers et des clés du registre à la transaction. Si tous les changements réussissent, l'application valide la transaction et les changements sont appliqués, mais à tout moment et jusqu'à ce point, elle peut restaurer la transaction, auquel cas les changements sont supprimés.

Un autre avantage est que les autres applications ne voient pas les modifications apportées à une transaction donnée, tant que celle-ci n'est pas validée. Les applications qui utilisent le DTC de Windows Vista et le futur Windows Server®, dont le nom de code est « Longhorn, » peuvent coordonner leurs transactions avec SQL Server™, Microsoft® Message Queue Server (MSMQ) et d'autres bases de données. Un service de mise à jour des applications qui se sert des transactions KTM ne laissera donc jamais une application dans un état incohérent. C'est pourquoi la mise à jour et la restauration du système Windows utilisent des transactions.

KTM, véritable cœur de la prise en charge des transactions, permet aux gestionnaires de ressources transactionnelles, tels que NTFS et le registre, de coordonner leurs mises à jour pour un ensemble spécifique de modifications faites par une application donnée. Dans Windows Vista, NTFS utilise une extension afin de prendre en charge les transactions appelées TxF. Le registre utilise une extension similaire appelée TxR. Ces gestionnaires de ressources en mode noyau travaillent avec le KTM pour coordonner l'état des transactions, exactement de la même façon que les gestionnaires de ressources en mode utilisateur utilisent le DTC pour coordonner l'état des transactions parmi une multitude de gestionnaires de ressources en mode utilisateur. Les parties tierces peuvent également utiliser KTM pour mettre en place leurs propres gestionnaires de ressources.

TxF et TxR définissent tous deux un nouvel ensemble d'API de système de fichiers et de registre, similaires à ceux qui existent, sauf qu'ils incluent un paramètre de transaction. Si une application veut créer un fichier dans une transaction, elle utilise d'abord KTM pour créer la transaction, puis passe la gestion de la transaction résultante à l'API de création du nouveau fichier.

TxF et TxR s'appuient tous deux sur la fonctionnalité d'enregistrement ultra-rapide du système de fichiers du Common Log File System (%Sys­tem­Root%\System32\Clfs.sys), introduit dans Windows Server 2003 R2. TxR et TxF utilisent CLFS pour durablement enregistrer les modifications de l'état des transactions avant de valider ces transactions. Ceci leur permet de fournir une récupération des transactions et des assurances, même en cas de court-circuit. Outre le journal CLFS, TxR crée un ensemble de fichiers de journaux apparentés pour suivre les modifications de transactions apportées au fichier du registre du système dans %Systemroot%\System32\Config\Txr, tel que le montre la figure 1, et sépare les fichiers de journaux pour la ruche de registre de chaque utilisateur. TxF enregistre des données transactionnelles pour chaque volume dans un répertoire masqué sur le volume nommé $Ex­tend\$RmMetadata.

Figure 1** Fichiers d'enregistrement TxR de la ruche de registre du système  **(Cliquer sur l'image pour l'agrandir)

Prise en charge améliorée des incidents

Lorsque Windows rencontre une erreur en mode noyau irrécupérable - que ce soit en raison d'un blocage au niveau du pilote d'un périphérique, de matériel défectueux ou du système d'exploitation - il essaie d'empêcher l'altération des données du disque en arrêtant le système après avoir affiché le fameux « écran bleu de mort » et, si la configuration le permet, en écrivant le contenu d'une partie ou de l'intégralité de la mémoire physique vers un fichier de décharge d'incidents. Les fichiers de décharge sont utiles car lorsque vous redémarrez après un incident, le service d'analyse en ligne des incidents de Microsoft (OCA) propose de les analyser afin de déterminer la cause d'origine. Si vous le souhaitez, vous pouvez également les analyser en utilisant les outils de débogage Microsoft pour Windows).

Cependant, dans les versions précédentes de Windows, la prise en charge des fichiers de décharge d'incidents était inactive tant que le processus Gestionnaire de sessions (%Systemroot%\Sys­tem32\Smss.exe) ne commençait pas la pagination des fichiers. Ceci voulait dire que toutes les erreurs critiques survenant avant ce point affichaient un écran bleu, mais pas de fichier de décharge. Puisque la plus grande partie de l'initialisation des pilotes de périphérique se produit avant le démarrage de Smss.exe, les premiers incidents n'entraînaient jamais la création de fichiers de décharge, rendant ainsi extrêmement difficile de diagnostiquer la cause de ce problème.

Windows Vista réduit l'intervalle au cours duquel aucun fichier de décharge n'est généré par l'initialisation de la prise en charge de ces fichiers, une fois que tous les pilotes de périphérique de démarrage ont été initialisés, mais avant de charger les pilotes de démarrage du système. À cause de cette modification, si vous rencontrez un incident au cours de la période initiale du processus de démarrage, le système peut capturer une décharge d'incidents, permettant à OCA de vous aider à résoudre le problème. De plus, Windows Vista enregistre les données dans un fichier de décharge en blocs de 64 Ko, tandis que les versions précédentes de Windows les écrivaient en blocs de 4 Ko. Cette modification entraîne la création de grands fichiers de décharge écrits jusqu'à 10 fois plus rapidement.

Dans Windows Vista, la gestion des incidents d'application est également améliorée. Dans les versions précédentes de Windows, lorsqu'une application plantait, elle exécutait un gestionnaire d'exceptions non gérées. Le gestionnaire lançait le processus de signalement d'erreurs d'application de Microsoft (AER) (%Systemroot%\System32\Dwwin.exe) pour afficher une boîte de dialogue indiquant que le programme avait planté et vous demandant si vous vouliez envoyer un rapport d'erreur à Microsoft. Cependant, si la pile du fil principal du processus était corrompue pendant l'incident, le gestionnaire d'exceptions non gérées plantait lors de son exécution, entraînant l'arrêt du processus par le noyau, la disparition immédiate des fenêtres du programme et l'absence de boîte de dialogue pour le signalement des erreurs.

Windows Vista déplace la gestion des erreurs hors du contexte du processus de plantage vers un nouveau service, Windows Error Reporting (WER). Ce service est mis en place par une DLL (%Sys­temroot%\System32\Wersvc.dll) au sein d'un processus d'hébergement de services. Lorsqu'une application plante, elle continue d'exécuter le gestionnaire d'exceptions non gérées, mais ce gestionnaire envoie un message au service WER, lequel lance le processus de signalement des fautes WER (%Systemroot%\System32\Werfault.exe) pour afficher la boîte de dialogue de signalement des erreurs. Si la pile est corrompue et que le gestionnaire d'exceptions non gérées plante, le gestionnaire continuera de s'exécuter et de planter, finissant par consommer toute la pile du fil (zone de mémoire « scratch ») ; c'est alors que le noyau intervient et qu'il envoie le message de notification du plantage au service.

Vous pouvez voir le contraste entre ces deux approches dans les figures 2 et 3, lesquelles montrent la relation entre les processus d'Accvio.exe, un programme de test qui plante, et les processus de signalement d'erreurs soulignés en vert, sur Windows XP et Windows Vista. Avec la nouvelle architecture de gestion des erreurs de Windows Vista, les programmes ne s'arrêteront plus de façon silencieuse sans offrir à Microsoft la possibilité d'obtenir un rapport d'erreur et sans aider les développeurs à améliorer leurs applications.

Figure 2a** Gestion des erreurs d'application dans Windows XP **(Cliquer sur l'image pour l'agrandir)

Figure 2b(Cliquer sur l'image pour l'agrandir)

Figure 3a** Gestion des erreurs d'application dans Windows Vista **(Cliquer sur l'image pour l'agrandir)

Figure 3b

Cliché instantané des volumes

Windows XP a introduit une technologie appelée Cliché instantané des volumes pour prendre des clichés des volumes du disque à un moment donné. Les applications de sauvegarde peuvent utiliser ces clichés pour créer des images de sauvegarde cohérentes. Cependant, ces clichés sont normalement masqués et conservés uniquement pendant la durée du processus de sauvegarde.

Les clichés ne sont en fait pas des copies complètes des volumes. Ce sont plutôt des vues d'un volume d'un moment antérieur comprenant les données de volume actives superposées aux copies des secteurs de volume, qui, depuis la prise du cliché, ont été modifiées. Le pilote Fournisseur de clichés de volumes (%Systemroot\%System32\Drivers\Volsnap.sys) contrôle les opérations destinées aux volumes et crée des copies de sauvegarde des secteurs avant de leur permettre d'être modifiées, stockant les données d'origine dans un fichier associé au cliché dans le répertoire du volume intitulé Informations sur les volumes du système.

Windows Server 2003 affichait la gestion des clichés aux administrateurs du serveur et aux utilisateurs des systèmes clients, grâce à ses clichés instantanés pour dossiers partagés. Cette fonctionnalité activait des clichés permanents, auxquels les utilisateurs pouvaient accéder via l'onglet Versions précédentes dans les boîtes de dialogue de propriétés de l'explorateur, ceci pour leurs dossiers et fichiers situés dans les partages de fichiers du serveur.

La fonctionnalité Versions précédentes de Windows Vista offre cette prise en charge à tous les systèmes clients, créant automatiquement des clichés de volumes, généralement une fois par jour. Vous pouvez y accéder via les boîtes de dialogue de propriétés de l'explorateur à l'aide de la même interface utilisée par les clichés instantanés pour dossiers partagés. Ceci vous permet d'afficher, de restaurer ou de copier des vieilles versions de fichiers et de répertoires que vous pourriez avoir accidentellement modifiées ou supprimées. Si du point de vue technique il ne s'agit pas d'une nouvelle technologie, la mise en place de la fonction Cliché instantané de volumes par la fonctionnalité Versions précédentes de Windows Vista optimise celle de Windows Server 2003 destinée aux environnements de postes de travail clients.

Windows Vista tire également parti des clichés de volumes pour unifier les mécanismes de protection des données de l'utilisateur et du système, ainsi que pour éviter d'enregistrer des données de sauvegarde redondantes. Lorsque l'installation d'une application ou le changement d'une configuration entraîne des comportements incorrects ou indésirables, vous pouvez utiliser la fonction Restauration du système, une fonctionnalité introduite dans la gamme de systèmes d'exploitation Windows NT ® de Windows XP visant à restaurer les fichiers et données du système tels qu'ils étaient lors de la création du point de restauration.

Dans Windows XP, la fonction Restauration du système fait appel à un pilote de filtre pour le système de fichiers — un type de pilote qui peut voir les modifications au niveau du fichier — afin de créer des copies de sauvegarde des fichiers du système lors de leur modification. Dans Windows Vista, cette fonction utilise les clichés de volume. Lorsque vous utilisez l'interface utilisateur Restauration du système de Windows Vista pour revenir à un point de restauration donné, vous copiez en fait les versions précédentes des fichiers de système modifiés à partir du cliché associé à ce point de restauration vers le volume actif.

BitLocker

Windows Vista est à ce jour la version la plus sûre de Windows. Outre l'inclusion du moteur antivirus Windows Defender, Windows Vista introduit de nombreuses fonctionnalités de sécurité et de défense approfondies, y compris le chiffrage complet de volumes BitLocker™, la signature de code pour le code en mode noyau, les processus protégés, la randomisation du chargement des espaces d'adressage et les améliorations apportées à la sécurité des services Windows et au Contrôle du compte utilisateur.

Un système d'exploitation peut uniquement appliquer ses stratégies de sécurité lorsqu'il est actif ; vous devez donc prendre des mesures supplémentaires pour protéger les données lorsque la sécurité physique d'un système peut être corrompue et qu'il est possible d'accéder aux données hors du système d'exploitation. Les mécanismes basés sur le matériel tels que les mots de passe et le chiffrage du BIOS sont deux technologies fréquemment utilisées pour empêcher les accès non autorisés, en particulier sur les ordinateurs portables, lesquels sont les plus susceptibles d'être perdus ou volés.

Windows 2000 a introduit le système de fichiers EFS (Encrypting File System) et, dans sa version Windows Vista, EFS inclut plusieurs améliorations par rapport aux mises en place précédentes, y compris des améliorations de performances, la prise en charge du chiffrage du fichier de pagination et le stockage des clés utilisateur EFS sur les cartes à puce. Cependant, vous ne pouvez pas utiliser EFS pour protéger l'accès aux zones sensibles du système, telles que les fichiers de la ruche du registre. Par exemple, si la Stratégie de groupe vous autorise à vous connecter sur votre ordinateur portable même lorsque vous n'êtes pas connecté à un domaine, vos vérificateurs d'authentification sont mis en cache dans le registre : un pirate pourrait alors utiliser des outils pour obtenir le hachage du mot passe de votre compte de domaine, puis se servir de cela pour retrouver votre mot de passe avec un outil de recherche de mot de passe. Ce mot de passe lui permettrait alors d'accéder à votre compte et à vos fichiers EFS (en supposant que vous n'avez pas enregistré la clé EFS sur une carte à puce).

Pour faciliter le chiffrage de l'intégralité du volume de démarrage (le volume accompagné du répertoire Windows), y compris tous ses fichiers et données de système, Windows Vista offre une fonctionnalité de chiffrage complet de volume appelée Windows BitLocker Drive Encryption. Contrairement à EFS, mis en place par le pilote du système de fichiers NTFS et fonctionnant au niveau du fichier, BitLocker chiffre au niveau du volume à l'aide du pilote Full Volume Encryption (FVE) (%Systemroot%\Sys­tem32\Drivers\Fve­vol.sys), tel que le montre le diagramme de la figure 4.

Figure 4** Pilote de filtre FVE de BitLocker **(Cliquer sur l'image pour l'agrandir)

FVE est un pilote de filtre ; il voit donc automatiquement toutes les requêtes d'E/S que NTFS envoie au volume, chiffrant les blocs au fur et à mesure de leur écriture et les déchiffrant lors de leur lecture, à l'aide de la clé Full Volume Encryption Key (FVEK) attribuée au volume lors de sa configuration initiale pour utiliser BitLocker. Par défaut, les volumes sont chiffrés en utilisant une clé AES de 128 bits et une clé de réflecteur de 128 bits. Puisque le chiffrage et le déchiffrage se produisent sous NTFS, dans le système E/S, le volume apparaît à NTFS comme s'il n'était pas chiffré, celui-ci n'ayant même pas besoin de savoir que BitLocker est activé. Cependant, si vous tentez de lire les données du volume hors de Windows, celles-ci auront une apparence aléatoire.

La clé FVEK est chiffrée avec une clé VMK (Volume Master Key) et stockée dans une zone de métadonnées spéciale du volume. Lorsque vous configurez BitLocker, vous disposez d'un nombre d'options vous permettant de déterminer comment la clé VMK sera protégée, en fonction des capacités du matériel du système. Si le système a un module TPM (Trusted Platform Module) conforme à la v1.2 de la spécification TPM et qu'il est associé à une prise en charge du BIOS, vous pouvez alors chiffrer la clé VMK avec le TPM, exiger que le système chiffre la clé VMK en utilisant une clé stockée dans le TPM et une autre conservée dans le périphérique USB à mémoire flash ou chiffrer la clé à l'aide d'une clé stockée dans le TPM et d'un PIN que vous saisissez au démarrage du système. Pour les systèmes qui n'ont pas de TPM, BitLocker propose de chiffrer la VMK en utilisant une clé stockée sur un périphérique USB externe à mémoire flash. Dans tous les cas, vous aurez besoin d'un volume de système NTFS non chiffré de 1.5 Go dans lequel sont stockés le Gestionnaire de démarrage et la Base de données de configuration du démarrage (BCD).

L'utilisation d'un TPM est avantageuse car BitLocker se sert des fonctionnalités TPM pour s'assurer de ne pas déchiffrer et déverrouiller le volume de démarrage si le BIOS ou les fichiers de démarrage du système ont été modifiés, étant donné que BitLocker était activé. Lorsque vous chiffrez le volume du système pour la première fois, et chaque fois que vous mettez à jour l'un des composants mentionnés, BitLocker calcule les hachages SHA-1 de ces composants et enregistre chacun d'entre eux, ce qui s'appelle une mesure, dans différents PCR (Platform Configuration Registers) du TPM à l'aide du pilote de périphérique de ce dernier (%Systemroot%\Sys­tem32\Drivers\Tpm.sys). Il utilise ensuite le TPM pour sceller la VMK, une opération qui utilise une clé privée stockée dans le TPM pour chiffrer la VMK et les valeurs stockées dans les PCR avec les autres données que BitLocker passe au TPM. BitLocker stocke ensuite la VMK scellée et la FVEK chiffrée dans la zone de métadonnées du volume.

Lorsque le système démarre, il mesure son propre hachage et code de chargement PCR et écrit le hachage du premier PCR du TPM. Il hache ensuite le BIOS et stocke cette mesure dans le PCR approprié. À son tour, le BIOS hache le composant suivant de la séquence de démarrage, le MBR (Master Boot Record) du volume de démarrage, et ce processus continue jusqu'à ce que le chargeur du système d'exploitation soit mesuré. Chaque partie subséquente de code qui s'exécute est responsable de mesurer le code qu'elle charge et de stocker la mesure dans le registre approprié du TPM. Pour finir, lorsque l'utilisateur sélectionne le système d'exploitation à démarrer, le Gestionnaire de démarrage (Bootmgr) lit la VMK chiffrée à partir du volume et demande au TPM de la desceller. Le TPM déchiffrera correctement la VMK uniquement si toutes les mesures sont identiques à celles qui étaient en vigueur au moment du scellage de la VMK, y compris le PIN facultatif.

Vous pouvez considérer ce plan comme une chaîne de vérification où chaque composant de la séquence de démarrage décrit le composant suivant au TPM. Le TPM divulguera son secret uniquement si toutes les descriptions correspondent à celles d'origine qui lui ont été données. BitLocker protège donc les données chiffrées même lorsque le disque est supprimé et placé dans un autre système, que le système démarre à l'aide d'un système d'exploitation différent ou que les fichiers non chiffrés sur le volume de démarrage sont compromis.

Vérification de l'intégrité du code

Les logiciels malveillants qui sont implémentés comme pilotes de périphérique en mode noyau, y compris les rootkits, s'exécutent à un niveau de privilège identique à celui du noyau ; ainsi, ces programmes sont les plus difficiles à identifier et à supprimer. Ce type de logiciel peut modifier le comportement du noyau et des autres pilotes jusqu'à devenir pratiquement invisible. L'intégrité du code de Windows Vista pour la fonctionnalité de code en mode noyau, également connue sous le nom de signature de code en mode noyau (KMCS), autorise le chargement des pilotes de périphérique seulement s'ils sont publiés et signés numériquement par des développeurs approuvés par l'une des peu nombreuses autorités de certification. Le KMCS est appliqué par défaut sur Windows Vista pour les systèmes de 64 bits.

Puisque les autorités de certification facturent leurs services et procèdent à des vérifications de base, telles que la vérification de l'identité d'une entreprise, il est plus difficile de produire un logiciel malveillant anonyme en mode noyau qui s'exécute sur Windows Vista 64 bits. De plus, si un logiciel malveillant réussit à s'infiltrer via le processus de vérification et qu'il est découvert sur un système corrompu, il peut laisser des indices qui permettent de remonter à son auteur. Le KMCS a également d'autres utilisations, comme la fourniture de coordonnées à l'équipe d'analyse en ligne des incidents Windows, lorsqu'un pilote est soupçonné d'avoir un bogue qui plante les systèmes clients, et le déverrouillage de contenu multimédia de haute définition, que je décrirai bientôt.

Le KMCS se sert des technologies de chiffrage à clé publique, utilisées par Windows depuis plus d'une décennie, et a besoin que le code en mode noyau comprenne une signature numérique générée par l'une des autorités de certification de confiance. Si un éditeur soumet un pilote au Microsoft Windows Hardware Quality Laboratory (WHQL) et que le pilote réussit l'essai de fiabilité, c'est Microsoft qui agira en tant qu'autorité de certification. La plupart des éditeurs obtiendront des signatures à l'aide de WHQL, mais lorsqu'un pilote n'a pas de programme de test WHQL, que l'éditeur ne veut pas se soumettre à l'essai WHQL ou que le pilote est un pilote de démarrage qui se charge tôt dans le démarrage du système, les éditeurs doivent signer le code eux-mêmes. Pour ce faire, ils doivent d'abord obtenir un certificat de signature de code de l'une des autorités de certifications que Microsoft estime être de confiance pour la signature de code en mode noyau. Ensuite, l'auteur hache numériquement le code, signe le hachage en le chiffrant avec une clé privée et insère le certificat et le hachage chiffré dans le code.

Lorsqu'un pilote essaie de se charger, Windows déchiffre le hachage inséré dans le code en utilisant la clé publique stockée dans le certificat, puis vérifie que le hachage correspond à celui inséré dans le code. L'authenticité du certificat est vérifiée de la même façon, mais en utilisant la clé publique de l'autorité de certification, incluse dans Windows.

Windows vérifie également les chaînes de certificats associées jusqu'à l'une des autorités racine intégrées dans le chargeur de démarrage et le noyau du système d'exploitation de Windows. Il ne faut jamais essayer de charger un pilote de 64 bits non signé sur un système de production, donc, contrairement au Gestionnaire Plug-and-play, qui affiche une boîte de dialogue d'avertissement lorsqu'on lui demande de charger un pilote qui n'a pas de signature confirmant qu'il a passé un essai WHQL, Windows Vista 64 bits écrit silencieusement un événement dans le journal des événements d'applications relatives à l'intégrité du code, comme celui qui apparaît dans la figure 5, chaque fois que le chargement d'un pilote non signé est bloqué. Windows 32 bits vérifie également les signatures des pilotes, mais autorise le chargement des pilotes non signés. Les bloquer briserait les systèmes Windows XP mis à niveau, car ils nécessitent des pilotes chargés sur Windows XP, et autoriserait également la prise en charge du matériel pour lequel seuls des pilotes Windows XP existent. Cependant, Windows Vista 32 bits écrit également des événements dans le journal des événements d'intégrité du code lors du chargement d'un pilote non signé.

Figure 5** Événements non signés de tentatives de chargement de pilotes **(Cliquer sur l'image pour l'agrandir)

Puisque la signature de code est habituellement utilisée pour étiqueter le code comme une version officielle rigoureusement testée, les éditeurs ne veulent en général pas signer le code de test. Windows Vista inclut donc un mode de signature de test que vous pouvez activer et désactiver avec l'outil de Bcdedit (décrit dans mon article de Technet Magazine de mars 2007), où il chargera les pilotes en mode noyau signés numériquement avec un certificat de test produit par une autorité de certification interne. Ce mode est conçu pour être utilisé par des programmeurs lorsqu'ils développent leur code. Lorsque ce mode est activé dans Windows, des marqueurs s'affichent sur le bureau, tel que le montre la figure 6.

Figure 6** Mode de signature de test de Windows Vista **

Processus protégés

Le contenu multimédia prochaine génération, tel que les DVD HD, BluRay et autres formats autorisés par le système AACS (Advanced Access Content System), sera plus répandu lors des années à venir. Windows Vista inclut plusieurs technologies, appelées PMP (Protected Media Path), exigées par la norme AACS pour que ce contenu soit lu. Les PMP incluent le PUMA (Protected User-Mode Audio) et le PVP (Protected Video Path), lesquels fournissent à eux deux les mécanismes nécessaires aux pilotes audio et vidéo, ainsi que les applications de lecteurs de supports numériques, afin d'empêcher les logiciels ou le matériel non autorisé de capturer du contenu de haute définition.

PUMA et PVP définissent les interfaces et la prise en charge spécifiques aux lecteurs audio et vidéo, aux pilotes de périphérique et au matériel, mais PMP se base également sur un mécanisme de noyau général introduit dans Windows Vista, appelé processus protégé. Les processus protégés se fondent sur la construction de processus standards Windows qui encapsulent une image exécutable en cours de fonctionnement, ses DLL, son contexte de sécurité (le compte sous lequel le processus s'exécute et ses privilèges de sécurité) et les fils qui exécutent le code dans le processus, mais empêchent certains types d'accès.

Les processus standards mettent en place un modèle de contrôle d'accès qui octroie au propriétaire du processus et des comptes administrateur un accès complet, grâce au privilège Déboguer les programmes. L'accès complet permet à un utilisateur de visualiser et de modifier l'espace d'adressage du processus, y compris le code et les données mappés dans le processus. Les utilisateurs peuvent également injecter des fils dans le processus. Ces types d'accès ne sont pas conformes aux exigences de PMP parce qu'ils permettraient au code non autorisé d'avoir accès au contenu haute définition et aux clés de gestion des droits numériques (DRM) stockées dans un processus qui lit le contenu.

Les processus protégés restreignent l'accès à un ensemble limité d'interfaces de gestion des informations et des processus qui incluent les requêtes de nom d'image du processus, ainsi que l'arrêt ou la suspension du processus. Mais le noyau met à disposition les informations diagnostiques des processus protégés via les fonctions générales de requêtes de processus, lesquelles retournent des données concernant tous les processus d'un système particulier et ne nécessitent donc pas un accès direct au processus. Les accès qui pourraient corrompre les supports numériques sont uniquement autorisés par d'autres processus protégés.

De plus, afin d'empêcher les corruptions de l'intérieur, tout le code exécutable chargé dans un processus protégé, y compris son image et ses DLL exécutables, doit être signé par Microsoft (WHQL) avec un indicateur Environnement protégé (PE) ou, s'il s'agit d'un codec audio, par un développeur disposant d'un certificat de signature DRM obtenu auprès de Microsoft. Puisque le code en mode noyau peut avoir un accès complet à tous les processus, y compris les processus protégés, et que Windows 32 bits autorise le chargement du code non signé en mode noyau, le noyau fournit une API pour les processus protégés afin d'interroger la « propreté » de l'environnement en mode noyau et d'utiliser le résultat pour déverrouiller le contenu essentiel, seulement si aucun code non signé est chargé.

Identification d'un processus protégé

Aucun API n'identifie en particulier les processus protégés, mais vous pouvez les identifier indirectement en fonction des informations limitées disponibles et parce qu'ils sont impossibles à déboguer, même à partir d'un compte administrateur. Le processus Audio Device Graph Isolation (%Systemroot%\System32\Audiodg.exe) est utilisé pour lire les DVD codés CSS (Content Scramble System) et peut s'identifier comme un processus protégé dans le volet Gestionnaire des tâches par le fait que ce Gestionnaire des tâches ne peut obtenir sa ligne de commande, sa virtualisation et son état Interdire l'exécution des données, même lorsqu'il est exécuté avec des droits administratifs.

Visualisation du processus protégé audiodg par le Gestionnaire des tâches(Cliquer sur l'image pour l'agrandir)

Randomisation du chargement de l'espace d'adressage

Malgré les mesures comme Interdire l'exécution des données et la vérification améliorée des erreurs du compilateur, les auteurs de logiciels malveillants continuent à rechercher des failles dans la saturation de la mémoire tampon qui leur permettraient d'infecter des processus ouverts sur le réseau, tels qu'Internet Explorer®, les services Windows et les applications tierces, afin de s'ancrer dans un système. Cependant, une fois qu'ils ont réussi à infecter un processus, ils doivent utiliser les API de Windows pour atteindre leur objectif ultime de lire des données utilisateur ou d'établir une présence permanente en modifiant les paramètres utilisateur ou de configuration du système.

La connexion d'une application aux points d'entrée API exportés par les DLL est généralement gérée par le chargeur du système d'exploitation, mais ces types d'infections générés par des logiciels malveillants ne peuvent pas tirer parti des services du chargeur. Dans les versions précédentes de Windows, ceci ne constituait pas un problème pour les logiciels malveillants, car pour chaque version de Windows, les images et les DLL exécutables du système se chargent toujours au même emplacement, permettant aux logiciels malveillants de supposer que les API résident à des adresses fixes.

La fonctionnalité de randomisation du chargement de l'espace d'adressage (ASLR) ne permet pas aux logiciels malveillants de savoir où sont situés les API, car elle charge les DLL et les exécutables du système à un endroit différent à chaque démarrage du système. Tôt dans le processus de démarrage, le Gestionnaire de mémoire choisit un biais aléatoire de chargement d'images DLL dans l'une des 256 adresses alignées de 64 Ko de la zone de 16 Mo située au-dessus de l'espace d'adressage du mode utilisateur. Lorsque les DLL disposant du nouvel indicateur de relocalisation dynamique dans leur en-tête d'image se chargent dans un processus donné, le Gestionnaire de mémoire les regroupe dans la mémoire, en commençant par l'adresse du biais de chargement des images.

Les exécutables dont l'indicateur est défini reçoivent un traitement similaire et se chargent à un endroit aléatoire aligné de 64 Ko dans les 16 Mo de l'adresse de chargement de base stockée dans leur en-tête d'image. De plus, si un DLL ou un exécutable donné se charge encore après avoir été déchargé par tous les processus l'utilisant, le Gestionnaire de mémoire sélectionne à nouveau un emplacement aléatoire où il peut le charger. La figure 7 montre un exemple de disposition de l'espace d'adressage pour un système Windows Vista 32 bits, y compris les zones à partir desquelles l'ASLR choisit le biais de chargement de l'image et l'adresse de chargement de l'exécutable.

Figure 7** Impact de l'ASLR sur les adresses de chargement des exécutables et des DLL **(Cliquer sur l'image pour l'agrandir)

Seules les images disposant de l'indicateur de relocalisation dynamique, ce qui inclut toutes les DLL et tous les exécutables de Windows Vista, sont relocalisées, car les images en mouvement héritées pourraient briser les suppositions internes que les développeurs ont faites concernant l'endroit de chargement de leurs images. Visual Studio® 2005 SP1 prend également en charge le paramétrage de l'indicateur pour que les développeurs tiers puissent tirer entièrement parti de l'ASLR.

La randomisation des adresses de chargement des DLL vers l'un des 256 emplacements n'empêche pas les logiciels malveillants de deviner l'emplacement correct d'une API, mais elle entrave sévèrement la vitesse à laquelle un vers de réseau peut se propager et empêche les logiciels malveillants, qui peuvent infecter le système une seule fois, de fonctionner de façon efficace. De plus, la stratégie de relocalisation de l'ASLR permet également de regrouper de façon plus serrée les espaces d'adressage par rapport aux versions précédentes de Windows, créant de plus grandes zones de mémoire libre pour les allocations de mémoire contiguës, réduisant le nombre de tableaux de page que le Gestionnaire de mémoire attribue pour suivre la disposition des espaces d'adressage et diminuant les ratés du TLB (Translation Lookaside Buffer).

Améliorations de la sécurité des services

Les services Windows sont des cibles idéales pour les logiciels malveillants. Beaucoup proposent un accès réseau à leur fonctionnalité, exposant potentiellement l'accès à un système exploitable à distance ; la plupart s'exécutent avec plus de privilèges que les comptes utilisateur standards, rendant possible l'élévation des privilèges sur un système local dans le cas où les logiciels malveillants parviennent à corrompre ces derniers. C'est pour cela que Windows a commencé à évoluer avec les modifications apportées à Windows XP SP2, lesquelles ont réduit les privilèges et l'accès attribués aux services à juste ceux nécessaires à leurs rôles. Par exemple, Windows XP SP2 a introduit les comptes Service local et Service réseau, incluant seulement un sous-ensemble des privilèges disponibles au compte dans lequel les services s'exécutaient auparavant toujours, c'est-à-dire le système local. Ceci minimise l'accès obtenu par un pirate lorsqu'il exploite un service.

Voir l'ASLR en action

Vous pouvez facilement voir les effets de l'ASLR en comparant les adresses de chargement des DLL pour un processus donné dans deux sessions de démarrage différentes en utilisant un outil comme Process Explorer de Sysinternals. Dans ces deux captures d'écran, prises de deux sessions différentes, Ntdll.dll s'est d'abord chargé dans Explorer à l'adresse 0x77A30000, puis à 0x77750000.

Différentes adresses de base de ntdll.dll(Cliquer sur l'image pour l'agrandir)

Différentes adresses de base de ntdll.dll(Cliquer sur l'image pour l'agrandir)

Dans mon article précédent, j'ai décrit comment les services s'exécutent de façon isolée par rapport aux comptes utilisateur dans leur propre session, mais Windows Vista développe également leur utilisation du principe de moindre privilège, en réduisant encore plus les privilèges et l'accès aux fichiers, aux clés de registre et aux ports de pare-feu qu'il attribue à la plupart des services. Windows Vista définit un nouveau compte de groupe, appelé Identifiant de sécurité de service (SID), unique à chaque service. Le service peut déterminer des autorisations sur ses ressources pour que seul son SID de service dispose d'un accès, empêchant les autres services s'exécutant dans le même compte utilisateur d'avoir un accès si un service devient corrompu. Vous pouvez voir le SID d'un service en utilisant la commande sc showsid, suivie par le nom du service, tel que le montre la figure 8.

Figure 8** Visualisation du SID d'un service **(Cliquer sur l'image pour l'agrandir)

Les SID de service protègent l'accès aux ressources possédées par un service donné, mais par défaut, les services ont toujours accès à tous les objets que peut atteindre le compte utilisateur dans lequel ils sont exécutés. Par exemple, un service s'exécutant dans le compte de Service local peut ne pas avoir accès à des ressources créées par un autre service s'exécutant en tant que Service local dans un processus différent ayant protégé ses objets avec des autorisations faisant référence à un SID de service. Cependant, il peut toujours lire et écrire les objets pour lesquels le Service Local (et tous les groupes auxquels appartient le Service local, comme le groupe de Service) a des autorisations.

Windows Vista introduit donc un nouveau type de service limité, appelé service limité à l'écriture, qui donne à un service des droits d'écriture uniquement pour les objets accessibles à son SID de service, au groupe Tout le monde et au SID attribué à l'ouverture de session. Pour ce faire, il utilise des SID limités, un type de SID introduit dans Windows 2000. Lorsque le processus ouvrant un objet est un service limité à l'écriture, l'algorithme de vérification des accès se modifie pour qu'un SID n'ayant pas été attribué à un processus à la fois sous forme limitée et illimitée ne puisse pas être utilisé pour accorder au processus un accès d'écriture à un objet donné. Vous pouvez voir si un service est limité avec la commande suivante :

sc qsidtype [service]

Une autre modification facilite l'interdiction à d'autres services s'exécutant dans le même compte d'avoir accès aux objets créés. Dans les versions précédentes de Windows, le créateur d'un objet est également le propriétaire de cet objet, et les propriétaires peuvent lire et modifier les autorisations de leurs objets, leur donnant un accès complet à leurs propres objets. Windows Vista introduit le nouvel SID Droits du propriétaire qui, s'il est présent dans les autorisations d'un objet, peut limiter les accès détenus par un propriétaire à son propre objet, ce qui supprime même le droit de configurer et d'interroger les autorisations.

Une autre amélioration au modèle de sécurité de service de Windows Vista active un développeur de service pour spécifier exactement de quels privilèges de sécurité le service a besoin pour fonctionner lorsque le service s'enregistre sur un système. Par exemple, si le service a besoin de produire des événements d'audit il pourrait lister le privilège Audit.

Lorsque le Gestionnaire de contrôle de service démarre un processus qui héberge un ou plusieurs services Windows, il crée un jeton de sécurité (l'objet de noyau qui liste un compte utilisateur de processus, les appartenances au groupe et les privilèges de sécurité) pour le processus qui inclut seulement les privilèges requis par les services dans le processus. Si un service spécifie un privilège qui n'est pas disponible pour le compte dans lequel il s'exécute, alors le service ne démarre pas. Lorsqu'aucun des services s'exécutant dans un processus de compte de Service local n'a besoin du privilège Déboguer les programmes, par exemple, le Gestionnaire de contrôle de service élimine ce privilège du jeton de sécurité du processus. Ainsi, si le processus du service est corrompu, le code malveillant ne peut pas profiter des privilèges qui n'étaient pas été explicitement demandés par les services s'exécutant dans le processus. La commande sc qprivs signale les privilèges qu'un service a demandés.

Conclusion

Ceci conclut mon analyse en trois parties des modifications du noyau de Windows Vista. Je n'ai pas couvert ou mentionné toutes les fonctionnalités et améliorations, telles que le nouveau regroupement de fils pour les développeurs d'applications, les nouveaux mécanismes de synchronisation comme les verrouillages partagés lecteur/rédacteur, l'étiquetage des fils de services, la prise en charge de la vérification du disque NTFS et le redimensionnement des volumes en ligne, ainsi que le nouveau mécanisme IPC du noyau appelé ALPC (Advanced Local Procedure Call). Recherchez plus d'informations sur ces sujets et autres fonctionnalités dans la prochaine édition de Windows Internals, dont la publication est prévue pour la fin 2007.

Visualisation du service limité à l'écriture

Seul un processus d'hébergement de services dans Windows Vista héberge des services limités. Vous pouvez l'identifier grâce à un outil de visualisation des processus tels que Process Explorer comme celui qui a la ligne de commande :

svchost -k LocalServiceNoNetwork

Les services configurés pour s'exécuter dans ce processus incluent le moteur de filtrage de base, le service de stratégie des diagnostics, le pare-feu Windows, les journaux et alertes de performances et le Windows Media® Center Service Starter.

Cet écran montre la forme textuelle du SID de service du moteur de filtrage de base, NT SERVICE\BFE, listé une fois avec l'indicateur Limité, puis une autre fois sans lui, pour que le processus accède aux ressources accessibles à ce compte. Cependant, il n'a pas nécessairement accès aux autres objets normalement accessibles au compte de Service local. Par exemple, puisque le compte NT AUTHORITY\SERVICE n'apparaît pas dans le jeton de processus avec l'indicateur limité, ce processus peut modifier les objets qui accordent un accès d'écriture unique à ce compte, mais pas aux autres comptes du jeton qui ont un indicateur limité.

Les services s'exécutant dans ce processus limitent également leurs privilèges, parce que les privilèges listés au bas de la boîte de dialogue de propriétés constituent un sous-ensemble de ceux disponibles au compte de Service local.

Indicateurs SID sur un service(Cliquer sur l'image pour l'agrandir)

Mark Russinovich est technicien dans le service responsable des plates-formes et services chez Microsoft. Il est coauteur de Microsoft Windows Internals (Microsoft Press, 2004) et intervient fréquemment lors de conférences informatiques et pour les développeurs, y compris Microsoft Tech•Ed et le symposium PDC. Il a rejoint nos équipes lorsque Microsoft a racheté Winternals Software, la société dont il était le cofondateur. Il a également créé Sysinternals, où il a publié de nombreux utilitaires populaires, notamment Process Explorer, Filemon et Regmon.

© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.