Nouvelles fonctionnalités de Win 7 : Console Host (ConHost.exe)

Aujourd'hui, je vais vous présenter la nouvelle fonctionnalité de Windows 7 / Windows Server 2008 R2 - hôte de console (ConHost.exe).

En fait, que ce soit en tant qu'utilisateurs ordinaires ou administrateurs d'entreprise, nous utiliserons plus ou moins les applications console dans nos applications Windows quotidiennes et dans nos processus d'exploitation et de maintenance. L'application console n'a pas d'interface utilisateur. Nous devons y effectuer des opérations d'entrée et de sortie via l'invite de commande (CMD, ce n'est pas DOS, beaucoup de gens sont confus).

Alors réfléchissons-y, avec quelles applications console Windows est-il fourni ?

En fait, les plus courants incluent cmd.exe, nslookup.exe et telnet.exe.

Dans les versions antérieures de Windows, toutes les applications qui représentaient des activités non-GUI (c'est-à-dire les applications console) étaient coordonnées via le processus système Csrss.exe lorsqu'elles voulaient s'exécuter sur le bureau. Lorsqu'une application console a besoin de recevoir des caractères, elle appelle une petite "API de console" dans Kernel32.dll pour permettre à Kernel32 de générer du LPC pour appeler CSRSS. À ce stade, CSRSS vérifiera la file d'attente d'entrée de la fenêtre de console et renverra les résultats du mode caractère à l'application console via Kernel32 pour association. Le mécanisme de traitement des messages des applications console dans les premières versions de Windows est illustré dans la figure ci-dessous :

Ce mécanisme de traitement a créé un problème : même si une application console est exécutée dans le contexte d'un utilisateur normal, Csrss.exe s'exécute toujours avec les autorisations du compte système local. Par conséquent, dans certains cas, les logiciels malveillants développés par des « méchants » peuvent obtenir davantage de privilèges via Csrss.exe exécuté avec les autorisations du compte système local. Ce mode d'attaque s'appelle Shatter Attack.

À l'ère de Win7 et de Windows Server 2008 R2, toutes les applications de console sont placées dans un nouveau processus contextuel ConHost.exe pour l'exécution, et ConHost (hôte de console) et les programmes de console s'exécutent dans le même contexte de niveau de sécurité, au lieu d'être émis. une demande de message LPC à CSRSS pour traitement, il demande à la place ConHost. Par conséquent, toute tentative d’application visant à exploiter une demande de message pour provoquer une élévation automatique des privilèges échouera. La figure suivante est un diagramme schématique du nouveau mécanisme utilisé dans Windows 7 et Windows Server 2008 R2 :

ConHost remplace un changement permanent dans la façon dont les E/S sont gérées par les applications de console. Les utilisateurs ne peuvent pas forcer Windows à revenir au comportement de la console en « mode hérité » via le registre ou la stratégie de groupe. Par conséquent, les utilisateurs doivent tester minutieusement les applications avant de passer à Windows 7 ou Windows Server 2008 R2. N'oubliez pas que même si la plupart des fonctions de certaines applications sont implémentées via l'interface graphique, les données sont toujours traitées par lots via la console ou d'autres interfaces fonctionnelles en arrière-plan. Par conséquent, il est absolument nécessaire d’effectuer des tests fonctionnels complets des applications avant la migration ou la mise à niveau.

Lorsqu'une application ne peut pas être utilisée normalement sous Windows 7, nous devons d'abord la tester et l'exécuter à nouveau avec les droits d'administrateur pour voir si le problème se produit. En fait, nous pouvons ensuite utiliser Process Monitor pour contrôler si les droits d'accès de l'application aux fichiers ou au registre. sont normaux. Si l'application ne peut toujours pas s'exécuter normalement après avoir résolu les problèmes ci-dessus, vous devez envisager de contacter l'ISV ou son développeur.

Si une application plante, le fichier de vidage sur incident correspondant est très utile aux développeurs et aux éditeurs de logiciels indépendants pour trouver le nœud du problème. Si l'application ne répond plus, vous pouvez essayer d'utiliser ADPlus pour la récupérer ainsi que le vidage du processus ConHost.exe associé. Les applications de console peuvent partager de nombreux sous-processus de la console Windows. Par exemple, lorsque l'utilisateur démarre Telnet à partir de la fenêtre CMD, Telnet.exe devient un sous-processus de Cmd.exe. Dans ce cas, l'hôte ConHost.exe traite les instances de message du processus parent et du processus enfant. En utilisant Process Explorer, nous pouvons confirmer quels processus ConHost.exe gère :

Vous pouvez également utiliser la fonction « Analyser la chaîne d'attente » dans le Moniteur de ressources Windows 7 pour afficher le processus d'application du processus ConHost.exe :

Enfin, n’oubliez pas de tester entièrement l’application avant la migration !