GetTempPath-Änderungen in der Vorschauversion des kumulativen Updates für Windows Februar

Zusammenfassung

Microsoft hat Sicherheitsverbesserungen für aktuelle Versionen von Windows eingeführt. Diese Sicherheitsverbesserungen ändern die Behandlung temporärer Pfade und können dazu führen, dass bestimmte .NET Framework und .NET-APIs wieSystem.IO.Path.GetTempPath()nach dem Anwenden des Patches einen anderen Speicherort zurückgeben.

Aktion erforderlich

Für .NET Framework oder ist keine Aktion erforderlich. NET-basierte Anwendung. Ihre Anwendung profitiert automatisch von allen Sicherheitsverbesserungen, die für Ihre Umgebung gelten. Die meisten Anwendungen beobachten keine Verhaltensänderungen.

Im weiteren Verlauf dieses Artikels erfahren Sie, wie Sie ermitteln können, ob sich diese Sicherheitsverbesserungen auf das Laufzeitverhalten Ihrer Anwendung auswirken können. In diesem Artikel werden auch Schritte zum Anpassen des Laufzeitverhaltens auf Wunsch aufgeführt.

Anwendbare Software

Dieser Artikel bezieht sich auf die folgende Software:

.NET 8 und höher
.NET Framework, alle Versionen, ab Juli 2024 Sicherheitsupdates und nachfolgende Updates

Nur bei Ausführung unter den folgenden Windows Update-Versionen:

Windows 10 Version 22H2, wenn KB5052077 installiert ist
Windows Server 2019, wenn KB5053594 installiert ist
Windows Server 2016, wenn KB5053594 installiert ist

Dieser Artikel gilt nicht für .NET Framework oder .NET, die unter Windows 11, Windows Server 2022 oder höher ausgeführt werden.

Dieser Artikel gilt nicht für .NET, wenn auf Nicht-Windows-Plattformen ausgeführt wird.

Ausführliche Beschreibung und Auswirkungserklärung

Seit den oben erwähnten Windows-Update-KBs hat Microsoft die Win32 GetTempPath2-API auf ältere marktinterne Versionen von Windows zurückportiert, um als sichereren Ersatz für die ältere Win32 GetTempPath-API zu fungieren. Intern basieren .NET Framework und .NET auf diese Win32-APIs, um die Implementierung der System.IO.Path.GetTempPath() -Methode bereitzustellen: Die Win32- GetTempPath2 -API wird bevorzugt, sofern vorhanden, und die Win32- GetTempPath -API wird als Fallback verwendet, wenn GetTempPath2 nicht vorhanden ist.

Da diese KBs die neue Win32- GetTempPath2 -API auf den entsprechenden Plattformen verfügbar machen, beginnen .NET Framework und .NET mit der Verwendung von GetTempPath2, sobald die KBs installiert wurden.

Die primäre Verhaltensänderung besteht darin, dass Aufrufer, die als SYSTEM-Identität ausgeführt werden, die System.IO.Path.GetTempPath() -Methode standardmäßig %WINDIR%\SystemTemp zurückgeben, während Aufrufer, die als eine andere als die SYSTEM-Identität ausgeführt werden, beobachten, dass die Methode weiterhin ihren vorhandenen Wert zurückgibt.

Wenn Ihre Anwendung alle folgenden Kriterien erfüllt, kann diese Änderung sie beeinträchtigen:

Ihre Anwendung verwendet eine Runtime- und Betriebssystemplattform, die unter der früheren Überschrift "Anwendbare Software" aufgeführt ist. und
Ihre Anwendung wird als SYSTEM-Identität ausgeführt. und
Sie legen die %TMP% oder %TEMP% Umgebungsvariable manuell fest, um den standardmäßigen Speicherort der temporären Datei umzuleiten. (Weitere Informationen finden Sie im Abschnitt "Hinweise " in der Dokumentation zur Win32- GetTempPath -API.)

Wenn Sie alle diese Kriterien erfüllen, können Sie nach der Installation der Windows-KBs beobachten, wie Ihre Anwendung in ein anderes temporäres Verzeichnis als das beabsichtigte Verzeichnis schreibt.

Diese Verhaltensänderung kann durch jede .NET Framework oder sichtbar sein. NET-bereitgestellte API, die schließlich auf GetTempPath2 basiert. Die häufigsten Einstiegspunkte sind:

Dies ist nicht als vollständige Liste von Methoden gedacht, deren Verhalten sich nach der Installation der KBs ändern kann.

Bestimmen, ob eine Anwendung unter der SYSTEM-Identität ausgeführt wird

Es gibt mehrere verschiedene Mechanismen zum Bestimmen der Identität einer .NET Framework- oder .NET-Anwendung.

IIS-basierte Webanwendungen

IIS bezieht sich auf die SYSTEM-Identität als "LOCALSYSTEM". Wechseln Sie im IIS-Manager (inetmgr.exe) zur Registerkarte Anwendungspools, um alle App-Pools und die zugehörigen Identitäten anzuzeigen. Sie können auch "Identität" in der Dropdownliste Gruppieren nach auswählen, um die Anzeige von App-Pools zu erleichtern, die als LOCALSYSTEM-Identität ausgeführt werden.

Der folgende Screenshot zeigt ein Beispiel für einen App-Pool ("MyAppPool"), der für die Ausführung als LOCALSYSTEM konfiguriert ist. Alle Anwendungen, die in diesem App-Pool ausgeführt werden, werden als SYSTEM-Identität ausgeführt.

Der Screenshot zeigt ein Beispiel für einen App-Pool ("MyAppPool"), der für die Ausführung als LOCALSYSTEM konfiguriert ist. Alle Anwendungen, die in diesem App-Pool ausgeführt werden, werden als SYSTEM-Identität ausgeführt.

Sie können auch programmgesteuert über eine PowerShell-Sitzung mit erhöhten Rechten auf diese Informationen zugreifen, indem Sie das folgende Skript verwenden.

Import-Module IISAdministration Get-IISAppPool | where {$_.ProcessModel.IdentityType -eq "LocalSystem"}

Auf einem Computer, der wie im obigen Screenshot mit einem App-Pool auf SYSTEMebene "MyAppPool" konfiguriert ist, gibt dieses PowerShell-Skript Folgendes aus, und zeigt an, dass "MyAppPool" unter der SYSTEM-Identität ausgeführt wird.

Name Status CLR Ver Pipeline Mode Start Mode ---- ------ ------- ------------- ---------- MyAppPool Started v4.0 Integrated OnDemand

Windows-Dienste

Wenn Ihr .NET Framework oder . NET-basierte Anwendung ist als Windows-Dienst registriert. Sie können den Dienst-Manager verwenden, um die zugehörige Identität anzuzeigen.

Führen Sie an einer Eingabeaufforderung mit erhöhten Rechten services.mscaus. Dadurch wird die Benutzeroberfläche des Dienst-Managers angezeigt.

Führen Sie an einer Eingabeaufforderung mit erhöhten Rechten services.msc aus. Dadurch wird die Benutzeroberfläche des Dienst-Managers angezeigt.

Wenn in der Spalte Anmelden als "Lokales System" für die Dienstidentität aufgeführt ist, wird der Dienst unter der SYSTEM-Identität ausgeführt.

Sie können diese Daten auch über PowerShell abfragen, indem Sie das Cmdlet Get-Service verwenden. Verwenden Sie beispielsweise den folgenden Befehl, um diese Informationen für einen Dienst mit dem Namen MyServiceabzufragen.

(Get-Service MyService).UserName -ieq "LocalSystem"

Wenn der Dienst für die Ausführung unter der SYSTEM-Identität registriert ist, wird True in der Konsole ausgegeben.

Andere Mechanismen

Tools wie Task-Manager (taskmgr.exe) oder Sysinternals Process Explorer können Ihnen auch mitteilen, ob eine Anwendung unter der SYSTEM-Identität ausgeführt wird.

Verwenden Sie im Task-Manager die Ansicht Details, um alle ausgeführten Prozesse im System aufzulisten, suchen Sie dann den relevanten Prozess, und sehen Sie sich den Eintrag in der Spalte Benutzername an.

Verwenden Sie im Task-Manager die Ansicht Details, um alle ausgeführten Prozesse im System aufzulisten, suchen Sie dann den relevanten Prozess, und sehen Sie sich den Eintrag in der Spalte Benutzername an.

Wenn der Wert benutzername "SYSTEM" lautet, wird der Prozess unter der SYSTEM-Identität ausgeführt.

Oder suchen Sie in Sysinternals Process Explorer den relevanten Prozess, und geben Sie die Ansicht Eigenschaften ein, und sehen Sie sich dann das Feld Benutzer auf der Registerkarte Bild an.

Suchen Sie in Sysinternals Process Explorer den relevanten Prozess, geben Sie die Ansicht Eigenschaften ein, und sehen Sie sich dann das Feld Benutzer auf der Registerkarte Bild an.

Wenn der Wert User "NT AUTHORITY\SYSTEM" lautet, wird der Prozess unter der SYSTEM-Identität ausgeführt.

Ändern des temporären Pfads für Prozesse auf SYSTEMebene

Das folgende PowerShell-Skript veranschaulicht, wie Sie ein neues Verzeichnis C:\NewSystemTemp\ erstellen und den Verzeichniszugriff nur auf Prozesse beschränken, die unter der SYSTEM-Identität ausgeführt werden. Versuchen Sie nicht, die ACLs eines Verzeichnisses zu ändern, das bereits mit Dateien aufgefüllt ist.

Dieses Skript muss in einer PowerShell-Sitzung mit erhöhten Rechten ausgeführt werden.

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

Sie können bestätigen, dass dieser Vorgang erfolgreich war, indem Sie den Befehl ausführen.

icacls C:\NewSystemTemp\

Dadurch wird die folgende Ausgabe erzeugt, die den Erfolg anzeigt:

C:\NewSystemTemp\ NT AUTHORITY\SYSTEM:(OI)(CI)(F) BUILTIN\Administrators:(OI)(CI)(F) Successfully processed 1 files; Failed processing 0 files

Legen Sie nach der Erstellung des Verzeichnisses die umgebungsvariable %SYSTEMTEMP% auf Systemebene fest. Sie können dies über die Benutzeroberfläche von System Systemsteuerung oder programmgesteuert über PowerShell festlegen:

[Environment]::SetEnvironmentVariable("SYSTEMTEMP", "C:\NewSystemTemp", [EnvironmentVariableTarget]::Machine)

Starten Sie dann den Computer neu.

Wenn Sie die umgebungsvariable %SYSTEMTEMP% ändern, wird der Rückgabewert von System.IO.Path.GetTempPath() für .NET Framework- und .NET-Anwendungen, die als andere Identität als SYSTEM ausgeführt werden, nicht geändert. Diese Anwendungen folgen weiterhin der gleichen Auflösungslogik, die sie immer haben, einschließlich der Berücksichtigung der %TMP% oder %TEMP% Umgebungsvariablen, falls sie vorhanden sind.

Ebenso ändert das Festlegen der umgebungsvariablen %TMP% oder %TEMP% den Rückgabewert von System.IO.Path.GetTempPath() für .NET Framework- und .NET-Anwendungen, die als SYSTEM-Identität ausgeführt werden.

Weitere Informationen

Weitere Informationen zu .NET Framework- und .NET-Verhalten finden Sie in der .NET-Dokumentation unter Path.GetTempPath.

Weitere Informationen zum zugrunde liegenden Verhalten des Windows-Betriebssystems finden Sie in der Windows-Dokumentation zur Win32 GetTempPath2-API.