Contrôle de compte d'utilisateur

Au cœur du contrôle de compte d'utilisateur Windows 7

Mark Russinovich

Vue d'ensemble :

• Comptes d'utilisateurs standard
• Contrôle de compte d'utilisateur

Sommaire

Technologies de contrôle de compte d'utilisateur
Élévations et sécurité contre les programmes malveillants
Différences dans Windows 7
Auto-élévation
Auto-élévation et objectifs du contrôle de compte d'utilisateur

Les comptes d'utilisateurs standard offrent une meilleure sécurité et un coût total de possession inférieur dans les environnements de professionnels et de particuliers. Lorsque les utilisateurs s'exécutent avec des droits utilisateur standard plutôt que des droits d'administration, la configuration de sécurité du système, y compris les programmes antivirus et pare-feu, est protégée. Ceci procure aux utilisateurs une zone sécurisée capable de protéger leur compte et le reste du système. Pour les déploiements en entreprise, les stratégies définies par les responsables informatiques ne peuvent pas être ignorées, tandis que sur un ordinateur partagé par toute la famille, les différents comptes d'utilisateurs sont protégés contre les modifications apportées par d'autres comptes.

Toutefois, les utilisateurs Windows ont toujours eu coutume de s'exécuter avec des droits d'administration. En conséquence, les logiciels sont fréquemment développés pour s'exécuter sous des comptes d'administration et assument des dépendances envers des droits d'administration, souvent de manière involontaire. Pour permettre à davantage de logiciels de s'exécuter avec des droits utilisateur standard et pour aider les développeurs à écrire des applications qui s'exécutent correctement avec des droits utilisateur standard, Windows Vista a introduit le contrôle de compte d'utilisateur. Il s'agit d'un ensemble de technologies incluant la virtualisation du Registre et des systèmes de fichiers, le compte d'administrateur protégé, les invites d'élévation de contrôle de compte d'utilisateur et les niveaux d'intégrité de Windows qui prennent en charge ces objectifs. J'ai traité ces différents aspects en détail dans mes présentations de conférence et dans l'article de TechNet Magazine intitulé UAC internals.

Windows 7 maintient les objectifs du contrôle de compte d'utilisateur avec des technologies sous-jacentes relativement inchangées. À noter toutefois l'introduction de deux nouveaux modes dans lesquels le compte d'administrateur protégé du contrôle de compte d'utilisateur peut opérer, ainsi qu'un mécanisme d'auto-élévation pour certains composants Windows intégrés. Dans le présent article, je vais discuter des motivations sous-jacentes aux technologies du contrôle de compte d'utilisateur, reparler de la relation entre le contrôle de compte d'utilisateur et la sécurité, décrire les deux nouveaux modes opératoires et expliquer le fonctionnement exact de l'auto-élévation. Notez que les informations fournies dans cet article reflètent le comportement de la version RC (Release Candidate) de Windows 7, qui diffère à plus d'un titre de celui de la version bêta.

Technologies du contrôle de compte d'utilisateur

L'avantage le plus évident et le plus significatif de la technologie du contrôle de compte d'utilisateur est qu'elle rend Windows simplement plus convivial. L'exemple le plus flagrant est la différence entre les exigences de privilèges liées à la définition du fuseau horaire dans Windows XP et Windows Vista. Sur Windows XP, la modification du fuseau horaire (et même le simple affichage du fuseau horaire à l'aide de l'applet Date/Heure du Panneau de configuration) requiert des droits d'administration.

Ceci est dû au fait que Windows XP ne fait pas la distinction entre la modification de l'heure, qui est une opération système pouvant affecter la sécurité, et la modification du fuseau horaire, qui affecte simplement la façon dont l'heure est affichée. Dans Windows Vista (et Windows 7), la modification du fuseau horaire n'est pas une opération administrative et l'applet Date/Heure du Panneau de configuration sépare les opérations administratives des opérations utilisateur standard. Ce simple changement permet à de nombreuses entreprises de pouvoir configurer les utilisateurs itinérants avec des comptes d'utilisateurs standard, car ces utilisateurs peuvent ajuster le fuseau horaire de façon à refléter leur emplacement géographique. Windows 7 va plus loin, car il permet aux utilisateurs standard d'accéder à des tâches telles que l'actualisation de l'adresse IP du système, l'utilisation de Windows Update pour installer des mises à jour et des pilotes facultatifs, la modification du paramètre PPP (point par pouce) de l'affichage et la visualisation des paramètres de pare-feu actifs.

La virtualisation du Registre et des systèmes de fichiers fonctionne en arrière-plan afin d'aider de nombreuses applications qui utilisent par inadvertance des droits d'administration à s'exécuter correctement sans eux. L'utilisation superflue des droits d'administration la plus courante concerne le stockage de paramètres d'applications ou de données utilisateur dans des zones du Registre ou du système de fichiers qui sont réservées à une utilisation par le système. Certaines applications héritées stockent leurs paramètres dans la partie du Registre à l'échelle du système (HKEY_LOCAL_MACHINE\Software) au lieu de la partie par utilisateur (HKEY_CURRENT_USER\Software), par exemple ; dans ce cas, la virtualisation du Registre dévie toute tentative d'écriture à l'emplacement système vers un emplacement dans HKEY_CURRENT_USER (HKCU) tout en préservant la compatibilité de l'application.

Le compte d'administrateur protégé a été conçu pour encourager les développeurs à écrire leurs applications de sorte qu'elles exigent uniquement des droits utilisateur standard tout en permettant au plus grand nombre d'applications qui partagent l'état entre des composants administratifs et des composants utilisateur standard de continuer à fonctionner. Par défaut, le premier compte sur un système Windows Vista ou Windows 7, qui était un compte d'administrateur complet dans les versions précédentes de Windows, est un compte d'administrateur protégé. Tout programme exécuté par un utilisateur de compte d'administrateur protégé s'exécute avec des droits utilisateur standard à moins que l'utilisateur n'élève l'application de manière explicite, auquel cas des droits d'administrateur sont accordés à l'application. Les invites d'élévation son déclenchées par des activités de l'utilisateur telles que l'installation d'applications et la modification de paramètres système. Ces invites d'élévation constituent la technologie de contrôle de compte d'utilisateur la plus visible ; elles se manifestent sous la forme d'un commutateur donnant accès à un écran avec une boîte de dialogue « autoriser/annuler » et un instantané grisé du Bureau comme arrière-plan.

Les comptes créés après l'installation sont par défaut des comptes d'utilisateurs standard qui fournissent la capacité d'élévation par le biais d'une invite « à la volée », où il faut fournir les informations d'identification d'un compte d'administration qui sera utilisé pour accorder des droits d'administration. Cette fonctionnalité permet à un membre de la famille de partager un ordinateur personnel ou à un utilisateur plus soucieux de la sécurité d'utiliser un compte d'utilisateur standard pour exécuter des applications avec des droits d'administration, à condition de connaître le mot de passe d'un compte d'administration, sans avoir à basculer manuellement vers une autre session utilisateur. Les programmes d'installation et la configuration du contrôle parental comptent parmi ces applications.

Lorsque le contrôle de compte d'utilisateur est activé, tous les comptes d'utilisateurs, y compris les comptes d'administrateurs, s'exécutent avec des droits utilisateur standard. Cela signifie que les développeurs d'applications doivent prendre en compte le fait que leurs logiciels ne disposeront pas de droits d'administration par défaut. Ils doivent par conséquent penser à concevoir leurs applications de sorte qu'elles fonctionnent avec des droits utilisateur standard. Si une application ou certaines de ses fonctionnalités requièrent des droits d'administration, elle peut faire appel au mécanisme d'élévation pour permettre à l'utilisateur de les déverrouiller. En général, il suffit aux développeurs d'applications d'apporter quelques modifications mineures à leurs applications pour qu'elles fonctionnent correctement avec des droits utilisateur standard. Comme le montre cet article du blog E7, le contrôle de compte d'utilisateur fait évoluer en bien la façon dont les développeurs écrivent les logiciels.

L'un des autres avantages offerts par les invites d'élévation est qu'elles « informent » l'utilisateur lorsqu'un logiciel souhaite apporter des modifications au système et qu'elles donnent à l'utilisateur la possibilité de l'en empêcher. Par exemple, si un package logiciel que l'utilisateur ne considère pas digne de confiance ou ne souhaite pas autoriser à modifier le système demande à disposer de droits d'administration, l'utilisateur peut décliner l'invite.

Élévations et sécurité contre les programmes malveillants

Le principal objectif du contrôle de compte d'utilisateur est de permettre à davantage d'utilisateurs de s'exécuter avec des droits utilisateur standard. Toutefois, l'une des ses technologies ressemble fortement à une fonctionnalité de sécurité : l'invite de consentement. De nombreuses personnes pensent que le fait qu'un logiciel doive obtenir de la part de l'utilisateur l'accord de droits d'administration signifie qu'ils peuvent empêcher des programmes malveillants d'obtenir des droits d'administration. Outre l'implication visuelle selon laquelle une invite est une passerelle vers les droits d'administration simplement pour l'opération qu'elle décrit, le basculement vers un Bureau différent pour la boîte de dialogue d'élévation et l'utilisation du mécanisme d'intégrité de Windows, y compris l'isolation des privilèges au niveau de l'interface graphique (UIPI), semblent renforcer cette croyance.

Comme nous l'avons déclaré bien avant la sortie de Windows Vista, l'objectif principal de l'élévation n'est pas la sécurité, bien que cela en constitue l'un des atouts : si les utilisateurs devaient basculer d'un compte à un autre pour effectuer des opérations administratives, soit en ouvrant une session sur un compte d'administration, soit par le biais de la fonction de changement rapide d'utilisateur, la plupart des utilisateurs basculeraient une fois et ne reviendraient pas sous leur session d'origine. Il n'y aurait aucun avantage à changer l'environnement pour lequel les développeurs conçoivent leurs applications. Alors, à quoi servent le Bureau sécurisé et le mécanisme d'intégrité de Windows ?

La principale raison du basculement vers un autre Bureau lors de l'invite est que les logiciels utilisateur standard ne peuvent pas « emprunter l'identité » de l'invite d'élévation, par exemple en dessinant par-dessus le nom de l'éditeur dans la boîte de dialogue en vue de faire croire à un utilisateur que c'est Microsoft ou un autre éditeur de logiciels qui génère l'invite, et non eux-mêmes. Cet autre Bureau porte le nom de « Bureau sécurisé » car son propriétaire est le système, et non simplement l'utilisateur, tout comme le Bureau sur lequel le système affiche la boîte de dialogue d'ouverture de session Windows.

L'utilisation d'un autre Bureau possède également un rôle important du point de vue de la compatibilité des applications : bien que les logiciels d'accessibilité intégrés, tels que le clavier visuel, fonctionnent bien sur un Bureau qui exécute des applications détenues par différents utilisateurs, ce n'est pas le cas de certains logiciels tiers. Ces logiciels ne fonctionnent pas correctement lorsqu'une boîte de dialogue d'élévation, dont le propriétaire est le compte système local, est affichée sur le Bureau dont l'utilisateur est propriétaire.

Le mécanisme d'intégrité de Windows et l'isolation des privilèges au niveau de l'interface graphique (UIPI) ont été conçus pour créer une barrière de protection autour des applications élevées. L'un de ses objectifs premiers consistait à empêcher les développeurs d'applications de prendre des raccourcis et d'exploiter des applications déjà élevées en vue d'accomplir des tâches administratives. Une application exécutée avec des droits utilisateur standard ne peut pas envoyer d'entrées de souris ou de clavier synthétiques dans une application élevée pour que celle-ci fasse son bon vouloir, ni injecter du code dans une application élevée pour effectuer des opérations administratives.

Le mécanisme d'intégrité de Windows et l'isolation des privilèges au niveau de l'interface graphique (UIPI) étaient utilisés dans Windows Vista pour Internet Explorer en mode protégé ; ainsi, il était plus difficile à un programme malveillant qui infectait une instance d'Internet Explorer en cours d'exécution de modifier des paramètres de comptes d'utilisateurs, par exemple pour se configurer lui-même afin de démarrer à chaque ouverture de session utilisateur. Bien que l'un des premiers objectifs de conception de Windows Vista était d'utiliser l'élévation avec le Bureau sécurisé, le mécanisme d'intégrité de Windows et la fonctionnalité UIPI pour créer une barrière infranchissable (appelée frontière de sécurité) entre les logiciels exécutés avec des droits utilisateur standard et ceux exécutés avec des droits d'administration, deux raisons ont empêché d'atteindre cet objectif, menant finalement à son abandon : la simplicité d'utilisation et la compatibilité des applications.

Figure 1 Affichage du nom du fichier exécutable.

Tout d'abord, considérons la boîte de dialogue d'élévation elle-même. Elle affiche le nom et l'éditeur du fichier exécutable principal auquel seront accordés des droits d'administration. Malheureusement, bien que de plus en plus d'éditeurs de logiciels signent numériquement leur code, tous ne le font pas et de nombreuses applications anciennes ne sont pas signées. Pour les logiciels non signés, la boîte de dialogue d'élévation affiche simplement le nom du fichier exécutable, ce qui permet à un programme malveillant déjà en cours d'exécution sur un compte d'utilisateur et à l'affût par exemple d'une élévation d'un programme d'installation d'application Setup.exe de remplacer le fichier exécutable par un fichier Setup.exe malveillant sans que l'utilisateur ne s'en rende compte (voir la Figure 1).

Ensuite, la boîte de dialogue n'indique pas à l'utilisateur quelles seront les DLL chargées par l'exécutable lors de son démarrage. Si l'exécutable réside dans un répertoire contrôlé par l'utilisateur, le programme malveillant exécuté avec les droits standard de l'utilisateur peut remplacer toute DLL associée à l'emplacement qui sera utilisé par le logiciel. Le programme malveillant pourrait également utiliser la fonctionnalité côte à côte pour faire en sorte que l'exécutable charge des versions malveillantes de DLL système ou de DLL d'application. Et à moins que l'utilisateur ne prenne le soin de cliquer sur le bouton Détails et n'examine soigneusement le chemin d'accès au fichier répertorié pour l'exécutable à élever, le programme malveillant peut copier l'exécutable dans un emplacement au nom similaire, par exemple \ProgramFiles\Vendor\Application.exe (notez l'espace manquant dans ce qui devrait être « Program Files »), où il pourrait contrôler les DLL chargées par l'application. Sur la Figure 2, j'ai copié un composant du Moniteur réseau Microsoft dans le répertoire C:\ProgramFiles créé et contrôlable par l'utilisateur et je l'ai lancé.

Figure 2 Copie lancée d'un composant du Moniteur réseau Microsoft.

Pour conclure, à des fins de compatibilité des applications, les applications élevées partagent un état conséquent avec l'environnement utilisateur standard qu'une application malveillante pourrait utiliser pour influencer le comportement d'une application élevée. L'exemple le plus clair est le profil de Registre de l'utilisateur, HKEY_CURRENT_USER (HKCU). Ce profil est partagé car les utilisateurs s'attendent à ce que les paramètres et extensions qu'ils inscrivent en tant qu'utilisateur standard fonctionnent dans les applications élevées. Des programmes malveillants pourraient utiliser des extensions d'environnement inscrites dans HKCU pour charger une application élevée qui utilisent l'une des boîtes de dialogue d'exploration d'environnement, comme Ouvrir le fichier et Enregistrer le fichier. D'autres types d'états sont également partagés, notamment l'espace de noms Base Named Object, où les applications créent des objets de synchronisation et de mémoire partagée. Des programmes malveillants pourraient tirer parti de ce partage pour détourner un objet mémoire partagé utilisé par une application élevée, par exemple pour compromettre l'application puis le système.

Comme pour le mécanisme d'intégrité de Windows, son efficacité en tant que barrière est limitée par les problèmes liés à l'élévation que j'ai mentionnés, mais il existe également des limitations dues à la compatibilité des applications. Pour commencer, la fonctionnalité UIPI n'empêche pas les applications utilisateur standard de dessiner sur le Bureau, processus qui pourrait être employé pour pousser l'utilisateur à interagir avec des applications élevées d'une manière qui accorderait des droits d'administration à un programme malveillant. En outre, le mécanisme d'intégrité de Windows ne se propage par sur le réseau. Une application utilisateur standard exécutée sur un compte d'administrateur protégé aura accès aux ressources système sur un système distant sur lequel ce compte d'administrateur protégé possède des droits d'administration. Les solutions à ces limitations ont des ramifications importantes en termes de compatibilité des applications. Ceci dit, nous cherchons en permanence à améliorer la sécurité du système, par exemple en améliorant Internet Explorer en mode protégé, tout en tentant de résoudre les problèmes de compatibilité des applications et en collaborant étroitement avec les développeurs de logiciels.

De quelle protection contre les programmes malveillants disposez-vous lorsque vous exécutez un compte d'administrateur protégé avec le contrôle de compte d'utilisateur activé ? Tout d'abord, souvenons-nous qu'en premier lieu il faut que le programme malveillant puisse accéder au système et s'exécuter. Windows possède de nombreux mécanismes de défense approfondis, tels que la Prévention de l'exécution des données (DEP), la Randomisation du chargement de l'espace d'adressage (ASLR), Internet Explorer en mode protégé, le filtre SmartScreen d'Internet Explorer 8 et Windows Defender, qui aident à empêcher les programmes malveillants d'accéder au système et de s'exécuter.

Quant aux scénarios dans lesquels des programmes malveillants parviennent à accéder au système car leurs auteurs (tout comme les développeurs légitimes) ont supposé que les utilisateurs s'exécutaient avec des droits d'administration, la plupart de ces programmes malveillants ne fonctionneront pas correctement. Seul, ceci pourrait être considéré comme un avantage pour la sécurité. Toutefois, un programme malveillant parvenu à accéder à un système et conçu pour exploiter cette opportunité pourrait être en mesure d'obtenir des droits d'administration la première fois que l'utilisateur effectue une élévation ; mais il n'est même pas nécessaire au programme malveillant d'attendre une « vraie » élévation car il pourrait en précipiter une qui tromperait l'utilisateur le plus soucieux de la sécurité. J'ai démontré publiquement la façon dont les programmes malveillants peuvent détourner le processus d'élévation dans mes présentations UAC Internals et Windows Security Boundaries (la démonstration figure après 1:03 minute durant la discussion sur les frontières de sécurité). Souvenons-nous tout de même qu'un programme malveillant qui commence à s'exécuter peut accomplir la plupart des tâches qu'il veut effectuer avec simplement des droits utilisateur standard, y compris se configurer lui-même pour s'exécuter chaque fois que l'utilisateur ouvre une session, dérober ou supprimer toutes les données de l'utilisateur, ou même faire partie d'un botnet.

Différences dans Windows 7

J'ai mentionné certaines des opérations dans Windows 7 qui peuvent maintenant être effectuées par des utilisateurs standard, mais comme l'explique le message de blog IE7 relatif au contrôle de compte d'utilisateur, nous avons également reconnu le fait qu'il était possible d'améliorer l'expérience Windows sans sacrifier les objectifs du contrôle de compte d'utilisateur. De nombreux utilisateurs se sont plaints du fait que Windows Vista demande fréquemment des droits d'administration lorsqu'ils effectuent des opérations de gestion système courantes. Il est dans notre intérêt, car il est dans l'intérêt de nos clients, de faire en sorte que Windows fonctionne correctement dans les environnements utilisateur standard. Les invites d'élévation forcent les utilisateurs à cliquer une seconde fois dans une boîte de dialogue que la vaste majorité des utilisateurs ne lisent pas. Nous avons par conséquent tenté de limiter ces invites dans Windows 7 par rapport à l'expérience Windows standard et de permettre aux utilisateurs de s'exécuter en tant qu'administrateurs afin de contrôler leur expérience d'invite.

Pour cela, nous avons refactorisé plus en détail le système de sorte qu'une personne disposant de droits utilisateur standard puisse exécuter davantage de tâches et nous avons réduit le nombre d'invites dans plusieurs scénarios à invites multiples (par exemple lors de l'installation d'un contrôle ActiveX dans Internet Explorer). Windows 7 propose également deux nouveaux modes opératoires de contrôle de compte d'utilisateur sélectionnables dans une nouvelle boîte de dialogue de configuration de contrôle de compte d'utilisateur (voir Figure 3). Vous pouvez ouvrir cette boîte de dialogue en accédant au Panneau de configuration, en cliquant sur Comptes d'utilisateurs, de nouveau sur Comptes d'utilisateurs, puis sur Modifier les paramètres de contrôle de compte d'utilisateur. (Vous pouvez également y accéder en cliquant sur le lien Modifier le moment d'affichage des notifications dans une invite d'élévation ou en passant par le Centre de maintenance.)

Figure 3 Deux nouveaux modes opératoires de contrôle de compte d'utilisateur sélectionnables dans une nouvelle boîte de dialogue de configuration de contrôle de compte d'utilisateur.

Le paramètre par défaut, illustré à la Figure 3, est l'un des nouveaux niveaux. Contrairement à Toujours m'avertir, qui est la sélection mentionnée en haut du curseur et qui est identique au mode par défaut dans Windows Vista, l'option par défaut dans Windows 7 affiche une invite à l'utilisateur uniquement lorsqu'un exécutable non-Windows demande une élévation ; le comportement pour les élévations non-Windows est identique à celui de Windows Vista.

La position inférieure suivante sur le curseur est celle du deuxième nouveau paramètre. Son étiquette est identique, hormis le fait qu'elle est suivie de la mention « (ne pas estomper mon Bureau) ». La seule différence entre ce mode et le mode par défaut réside dans le fait que les invites sont affichées sur le Bureau de l'utilisateur plutôt que sur le Bureau protégé. L'avantage est que l'utilisateur peut interagir avec le Bureau pendant qu'une invite est active, mais comme je l'ai fait remarquer plus haut, il y a un risque que des logiciels d'accessibilité tiers ne fonctionnent pas correctement dans la boîte de dialogue d'invite.

Pour finir, la position du curseur la plus basse désactive entièrement les technologies de contrôle de compte d'utilisateur : tous les logiciels exécutés dans un compte d'administrateur protégé s'exécutent avec des droits d'administration complets, la virtualisation du Registre et des systèmes de fichiers est désactivée et Internet Explorer en mode protégé est désactivé. Bien qu'aucune invite ne soit affichée dans ce mode, la perte d'Internet Explorer en mode protégé constitue un inconvénient majeur.

Auto-élévation

La raison pour laquelle l'élévation de la plupart des exécutables Windows avec les deux paramètres intermédiaires ne provoque pas l'affichage d'invites est que le système « auto-élève » les exécutables Windows. Tout d'abord, qu'est-ce que Windows définit comme un exécutable Windows dans ce contexte ? La réponse dépend de plusieurs facteurs, mais deux critères sont essentiels : l'exécutable doit être signé par l'éditeur Windows, qui est le certificat utilisé pour signer tout le code fourni avec Windows (il ne suffit pas qu'il soit signé par Microsoft ; par conséquent, les logiciels Microsoft non fournis avec Windows ne sont pas inclus), et il doit se trouver dans l'un des quelques répertoires « sécurisés ». Un répertoire sécurisé est un répertoire que les utilisateurs standard ne peuvent pas modifier, tel que %SystemRoot%\System32 (par exemple \Windows\System32) et la plupart de ses sous-répertoires, %SystemRoot%\Ehome, ainsi que quelques répertoires sous %ProgramFiles% qui incluent Windows Defender et le Journal Windows.

De plus, l'auto-élévation est soumise à des règles supplémentaires selon qu'il s'agit d'un exécutable normal, de Mmc.exe ou d'un objet COM. Les exécutables Windows (tels que définis ci-dessus) du type .exe sont auto-élevés s'ils spécifient la propriété autoElevate dans leur manifeste. C'est également dans leur manifeste que les applications indiquent au contrôle de compte d'utilisateur qu'elles souhaitent disposer de droits d'administration. Voici un exemple de l'utilitaire Sigcheck de Sysinternals vidant le manifeste du Gestionnaire des tâches (Taskmgr.exe) avec la commande « sigcheck –m %systemroot%\system32\taskmgr.exe », ce qui indique que le Gestionnaire des tâches est inscrit pour l'auto-élévation (voir Figure 4).

Figure 4 La propriété autoElevate

Pour identifier les exécutables à auto-élévation dans une arborescence de répertoires, il existe une méthode simple : faire appel à l'utilitaire Strings de Sysinternals avec une commande telle que la suivante :

strings –s *.exe | findstr /i autoelevate

Il existe également une liste codée en dur d'exécutables Windows qui bénéficient de l'auto-élévation. Ces exécutables Windows étant également fournis séparément de Windows 7, ils doivent être en mesure de s'exécuter sur des systèmes de bas niveau où la présence de la propriété autoexecute provoquerait une erreur. La liste inclut Migwiz.exe, l'Assistant de migration, Pkgmgr.exe, le gestionnaire de packages, et Spinstall.exe, l'installateur de Service Packs.

La console de gestion Microsoft, Mmc.exe, bénéficie d'un traitement particulier car elle héberge une grande partie des composants logiciels enfichables de gestion système, qui sont implémentés en tant que DLL. Mmc.exe est lancé avec une ligne de commande qui spécifie un fichier .MSC répertoriant les composants logiciels enfichables que la console MMC doit charger. Lorsque Windows constate que Mmc.exe demande des droits d'administration, ce qui est le cas lorsque cet exécutable est lancé depuis un compte d'administrateur protégé, il valide le fait que Mmc.exe est un exécutable Windows puis vérifie le fichier .MSC. Pour pouvoir bénéficier de l'auto-élévation, le fichier .MSC doit satisfaire les critères de fichier exécutable Windows (signature par Windows dans un emplacement sécurisé) et doit figurer sur une liste interne de fichiers .MSC à auto-élévation. Cette liste comprend pratiquement tous les fichiers .MSC fournis avec Windows.

Pour finir, les objets COM peuvent spécifier leur besoin de disposer de droits d'administration avec une valeur de Registre dans leur clé de Registre en créant une sous-clé nommée Elevation avec une valeur nommée Enabled définie sur 1. La Figure 5 illustre la clé de Registre pour l'objet Copy/Move/Rename/Delete/Link de l'environnement, laquelle est utilisée par l'Explorateur lorsqu'un utilisateur exécute une opération de système de fichiers sur un emplacement pour lequel son compte ne dispose pas d'autorisations.

Figure 5 Clé de Registre d'environnement

Pour qu'un objet COM soit auto-élevé, il doit également s'agir d'un exécutable Windows et il doit avoir été instancié par un exécutable Windows. (Toutefois, il n'est pas obligatoire que l'exécutable effectuant l'instanciation soit marqué pour l'auto-élévation.) Lorsque vous utilisez par exemple l'Explorateur pour créer un répertoire dans le répertoire %ProgramFiles% depuis un compte d'administrateur protégé, l'opération est auto-élevée car l'objet COM demande l'élévation, la DLL de l'objet est un exécutable Windows et l'Explorateur est un exécutable Windows.

Auto-élévation et objectifs du contrôle de compte d'utilisateur

Quel est le raisonnement sous-jacent à toutes les règles spéciales d'auto-élévation ? Le choix des éléments à auto-élever était guidé par la question suivante : « Un développeur d'applications peut-il dépendre par inadvertance de droits d'administration en exploitant l'auto-élévation ? ». Étant donné que Cmd.exe peut être utilisé pour exécuter des scripts de commandes par le biais d'arguments de ligne de commande et que l'utilisateur moyen n'a pas besoin d'exécuter des invites de commandes avec élévation (la plupart ne sait même pas ce qu'est une invite de commande), son auto-élévation n'a pas été retenue. De même, Rundll32.exe, l'exécutable qui héberge les plug-ins du Panneau de configuration, ne bénéficie pas d'auto-élévation dans la version finale de Windows 7 car son élévation n'est requise pour aucune tâche de gestion courante. S'il était auto-élevé, sa capacité à héberger des DLL arbitraires par le biais de sa ligne de commande pourrait faire en sorte qu'un développeur exige des droits d'administration sans s'en rendre compte.

Les utilisateurs finals demandent depuis la version bêta de Windows Vista à ce que Windows offre un moyen d'ajouter des applications arbitraires à la liste d'auto-élévation. La raison la plus citée est que certaines des applications tierces qu'ils utilisent fréquemment les obligent constamment à passer par une invite d'élévation dans le cadre de leurs activités quotidiennes. Windows 7, tout comme Windows Vista, n'offre pas ce genre de fonctionnalité. Nous comprenons la gêne occasionnée, et il se peut qu'il y ait une raison légitime pour laquelle ces applications ne peuvent s'exécuter sans droits d'administration, mais il existe un trop grand risque que les développeurs évitent de corriger leur code de sorte qu'il fonctionne avec des droits utilisateur standard. Même si la liste des applications qui bénéficient d'une auto-élévation était accessible uniquement par les administrateurs, les développeurs pourraient simplement modifier leur programme d'installation d'application, qui requiert une élévation ponctuelle, pour ajouter l'application à la liste. Nous avons plutôt choisi d'investir en termes de formation et de collaboration étroite avec les développeurs d'applications afin de s'assurer que leurs programmes fonctionnent correctement en tant qu'utilisateur standard.

Plusieurs personnes ont fait remarquer qu'il était possible à un logiciel tiers exécuté sur un compte d'administrateur protégé avec des droits utilisateur standard de tirer parti de l'auto-élévation pour obtenir des droits d'administration. Par exemple, le logiciel peut utiliser l'API WriteProcessMemory pour injecter du code dans l'Explorateur et l'API CreateRemoteThread pour exécuter ce code. Cette technique est appelée injection de DLL. Étant donné que le code s'exécute dans l'Explorateur, qui est un exécutable Windows, il peut utiliser les objets COM qui bénéficient d'une auto-élévation, comme l'objet Copy/Move/Rename/Delete/Link, pour modifier des répertoires ou des clés de Registre système et accorder au logiciel des droits d'administration. Bien que ce soit vrai, ces étapes requièrent une volonté marquée et ne sont pas triviales ; nous estimons donc qu'il est peu vraisemblable que des développeurs dignes de ce nom préfèrent adopter cette approche plutôt que de corriger leur logiciel de sorte qu'il fonctionne avec des droits utilisateur standard. En fait, nous déconseillons aux développeurs d'applications d'implémenter toute dépendance au comportement d'élévation dans le système et les encourageons à effectuer des tests afin de vérifier que leurs logiciels s'exécutent correctement en mode utilisateur standard.

L'observation qui en découle est qu'un programme malveillant pourrait obtenir des droits d'administration à l'aide des mêmes techniques. Là encore, on ne peut le nier, mais comme je l'ai fait remarquer plus haut, un programme malveillant peut également compromettre le système par le biais d'invites d'élévations. Du point de vue du programme malveillant, le mode par défaut de Windows 7 n'est ni plus ni moins sécurisé que le mode Toujours m'avertir (« mode Vista ») et un programme malveillant qui acquiert des droits d'administration sera toujours actif dans le mode par défaut de Windows 7.

Conclusion

Pour résumer, le contrôle de compte d'utilisateur est un ensemble de technologies ayant un objectif global : permettre aux utilisateurs de s'exécuter en tant qu'utilisateurs standard. Les différentes modifications apportées à Windows qui permettent aux utilisateurs standard d'effectuer davantage d'opérations qui nécessitaient auparavant des droits d'administration, la virtualisation des fichiers et du Registre, ainsi que les invites permettent d'atteindre cet objectif. Le mode de contrôle de compte d'utilisateur par défaut de Windows 7 rend l'expérience des utilisateurs de comptes d'administrateurs protégés plus fluide en réduisant le nombre d'invites, leur permet de contrôler les logiciels légitimes autorisés à modifier leur système et atteint tout de même l'objectif du contrôle de compte d'utilisateur qui consiste à permettre à davantage de logiciels de s'exécuter sans droits d'administration et à continuer de faire évoluer l'écosystème logiciel vers l'écriture de logiciels qui fonctionnent avec des droits utilisateur standard.

Mark Russinovich est associé technique au sein de la division Plateformes et services de Microsoft.