Date de publication :25 février 2025
Version :.NET 8 et versions ultérieures.NETFramework, toutes les versions
Résumé
Microsoft a déployé des améliorations de sécurité pour les versions récentes de Windows. Ces améliorations de sécurité modifient la gestion des chemins temporaires et peuvent entraîner le retour d’un autre emplacement après l’application du correctif par certaines API .NET Framework et .NET telles queSystem.IO.Path.GetTempPath().
Action requise
Aucune action n’est requise de .NET Framework ou . Application basée sur NET. Votre application bénéficie automatiquement des améliorations de sécurité applicables à votre environnement. La plupart des applications n’observent aucun changement de comportement.
Le reste de cet article explique comment déterminer si ces améliorations de sécurité peuvent avoir un impact sur le comportement d’exécution de votre application. Cet article répertorie également les étapes de personnalisation du comportement d’exécution si vous le souhaitez
Logiciels applicables
Cet article s’applique aux logiciels suivants :
-
.NET 8 et versions ultérieures
-
.NET Framework, toutes les versions, à compter des mises à jour de sécurité de juillet 2024 et des mises à jour suivantes
Uniquement en cas d’exécution sur les versions de mise à jour de Windows suivantes :
-
Windows 10, version 22H2 quand KB5052077 est installé
-
Windows Server 2019, quand KB5053594 est installé
-
Windows Server 2016, quand KB5053594 est installé
Cet article ne s’applique pas au .NET Framework ou au .NET exécuté sur Windows 11, Windows Server 2022 ou version ultérieure.
Cet article ne s’applique pas à .NET lors de l’exécution sur des plateformes non Windows.
Description détaillée et déclaration d’impact
À compter des bases de connaissances de mise à jour Windows mentionnées ci-dessus, Microsoft a rétroporté l’API Win32 GetTempPath2 vers des versions antérieures de Windows sur le marché pour remplacer plus sûrement l’ancienne API GetTempPath Win32. En interne, .NET Framework et .NET s’appuient sur ces API Win32 pour fournir l’implémentation de la méthode System.IO.Path.GetTempPath() : l’API Win32 GetTempPath2 est préférable si elle existe ; et l’API win32 GetTempPath est utilisée comme secours si GetTempPath2 n’existe pas.
Étant donné que ces bases de connaissances rendent la nouvelle API Win32 GetTempPath2 disponible sur les plateformes applicables, .NET Framework et .NET commencent à utiliser GetTempPath2 une fois les bases de connaissances installées.
Le principal changement de comportement est que les appelants qui s’exécutent en tant qu’identité SYSTEM observent que la méthode System.IO.Path.GetTempPath() retourne %WINDIR%\SystemTemp par défaut, tandis que les appelants qui s’exécutent comme autre chose que l’identité SYSTEM observent que la méthode continue à retourner sa valeur existante.
Si votre application répond à tous les critères ci-dessous, vous pouvez être affecté par cette modification :
-
Votre application utilise un runtime et une plateforme de système d’exploitation répertoriés sous l’en-tête « Logiciel applicable » précédent . et
-
Votre application s’exécute en tant qu’identité SYSTEM ; et
-
Vous définissez manuellement la variable d’environnement %TMP% ou %TEMP% pour rediriger l’emplacement du fichier temporaire standard. (Consultez la section Remarques de la documentation de l’API Win32 GetTempPath .)
Si vous répondez à tous ces critères, une fois les bases de connaissances Windows installées, vous pouvez observer que votre application écrit dans un répertoire temporaire autre que celui que vous avez prévu.
Ce changement de comportement peut être visible via n’importe quel .NET Framework ou . API fournie par NET qui s’appuie finalement sur GetTempPath2. Les points d’entrée les plus courants sont les suivants :
Il ne s’agit pas d’une liste exhaustive de méthodes dont les comportements peuvent changer une fois les bases de connaissances installées.
Déterminer si une application s’exécute sous l’identité SYSTEM
Il existe plusieurs mécanismes différents pour déterminer l’identité d’une application .NET Framework ou .NET
Applications web basées sur IIS
IIS fait référence à l’identité SYSTÈME en tant que « LOCALSYSTEM ». Dans le Gestionnaire des services Internet (inetmgr.exe), accédez à l’onglet Pools d’applications pour voir tous les pools d’applications et leurs identités associées. Vous pouvez également sélectionner « Identité » dans la liste déroulante Regrouper par pour faciliter l’affichage des pools d’applications qui s’exécutent en tant qu’identité LOCALSYSTEM.
La capture d’écran ci-dessous montre un exemple de pool d’applications (« MyAppPool ») configuré pour s’exécuter en tant que LOCALSYSTEM. Toutes les applications exécutées dans ce pool d’applications s’exécutent en tant qu’identité SYSTÈME.
Vous pouvez également accéder à ces informations par programme à partir d’une session PowerShell avec élévation de privilèges à l’aide du script ci-dessous.
Import-Module IISAdministration Get-IISAppPool | where {$_.ProcessModel.IdentityType -eq "LocalSystem"}
Sur un ordinateur configuré avec un pool d’applications « MyAppPool » de niveau SYSTÈME, comme illustré dans la capture d’écran ci-dessus, ce script PowerShell imprime ce qui suit, montrant que « MyAppPool » s’exécute sous l’identité SYSTEM.
Name Status CLR Ver Pipeline Mode Start Mode ---- ------ ------- ------------- ---------- MyAppPool Started v4.0 Integrated OnDemand
Services Windows
Si votre .NET Framework ou . L’application basée sur NET est inscrite en tant que service Windows. Vous pouvez utiliser le Gestionnaire de services pour afficher son identité associée.
À partir d’une invite de commandes avec élévation de privilèges, exécutez services.msc. L’interface utilisateur du Gestionnaire de services s’affiche.
Si la colonne Ouvrir une session en tant que répertorie « Système local » pour l’identité du service, le service s’exécute sous l’identité SYSTEM.
Vous pouvez également interroger ces données via PowerShell à l’aide de l’applet de commande Get-Service . Par exemple, pour interroger ces informations sur un service nommé MyService, utilisez la commande suivante.
(Get-Service MyService).UserName -ieq "LocalSystem"
Si le service est inscrit pour s’exécuter sous l’identité SYSTEM, la valeur True s’affiche sur la console.
Autres mécanismes
Des outils tels que le Gestionnaire des tâches (taskmgr.exe) ou Sysinternals Process Explorer peuvent également vous indiquer si une application s’exécute sous l’identité SYSTEM.
Dans le Gestionnaire des tâches, utilisez la vue Détails pour répertorier tous les processus en cours d’exécution dans le système, puis recherchez le processus qui vous intéresse et examinez l’entrée sous la colonne Nom d’utilisateur .
Si la valeur Nom d’utilisateur indique « SYSTEM », le processus s’exécute sous l’identité SYSTEM.
Ou, dans Sysinternals Process Explorer, recherchez le processus qui vous intéresse et entrez la vue Propriétés, puis examinez le champ Utilisateur sous l’onglet Image.
Si la valeur Utilisateur indique « NT AUTHORITY\SYSTEM », le processus s’exécute sous l’identité SYSTEM.
Modification du chemin d’accès temporaire pour les processus de niveau SYSTÈME
Le script PowerShell ci-dessous montre comment créer un répertoire C:\NewSystemTemp\ et restreindre l’accès au répertoire aux seuls processus s’exécutant sous l’identité SYSTEM. N’essayez pas de modifier les listes de contrôle d’accès d’un répertoire déjà rempli avec des fichiers.
Ce script doit être exécuté à partir d’une session PowerShell avec élévation de privilèges.
mkdir C:\NewSystemTemp\ $acl = New-Object System.Security.AccessControl.DirectorySecurity $acl.SetSecurityDescriptorSddlForm("O:SYG:SYD:PAI(A;OICI;FA;;;SY)(A;OICI;FA;;;BA)") Set-Acl C:\NewSystemTemp\ -AclObject $acl
Vous pouvez vérifier que cette opération a réussi en exécutant la commande
icacls C:\NewSystemTemp\
Ce qui produit la sortie suivante montrant la réussite :
C:\NewSystemTemp\ NT AUTHORITY\SYSTEM:(OI)(CI)(F) BUILTIN\Administrators:(OI)(CI)(F) Successfully processed 1 files; Failed processing 0 files
Une fois le répertoire créé, définissez la variable d’environnement %SYSTEMTEMP% avec l’étendue au niveau du système. Vous pouvez le définir via l’interface utilisateur Panneau de configuration système, ou vous pouvez le définir par programmation via PowerShell :
[Environment]::SetEnvironmentVariable("SYSTEMTEMP", "C:\NewSystemTemp", [EnvironmentVariableTarget]::Machine)
Redémarrez ensuite la machine.
La modification de la variable d’environnement %SYSTEMTEMP%ne modifie pas la valeur de retour de System.IO.Path.GetTempPath() pour les applications .NET Framework et .NET qui s’exécutent en tant qu’identité autre que SYSTEM. Ces applications continueront à suivre la même logique de résolution qu’elles ont toujours, notamment en respectant les variables d’environnement %TMP% ou %TEMP% si elles sont présentes.
De même, la définition de la variable d’environnement %TMP% ou %TEMP% ne modifie pas la valeur de retour de System.IO.Path.GetTempPath() pour les applications .NET Framework et .NET qui s’exécutent en tant qu’identité SYSTEM.
Pour plus d’informations
Pour plus d’informations sur les comportements .NET Framework et .NET, consultez la documentation .NET sur Path.GetTempPath.
Pour plus d’informations sur le comportement sous-jacent du système d’exploitation Windows, consultez la documentation Windows sur l’API Win32 GetTempPath2.
