Obs
- Premiärdatum:
Den 25 februari 2025 - Version:
.NET 8 och senare
.NET Framework, alla versioner
Sammanfattning
Microsoft har distribuerat säkerhetsförbättringar till de senaste versionerna av Windows. Dessa säkerhetsförbättringar ändrar hanteringen av tillfälliga sökvägar och kan göra att vissa API: er för .NET Framework och .NET returnerar System.IO.Path.GetTempPath()en annan plats när korrigeringen har tillämpats.
Åtgärd krävs
Ingen åtgärd krävs av .NET Framework eller . NET-baserat program. Ditt program drar automatiskt nytta av alla säkerhetsförbättringar som gäller för din miljö. De flesta program observerar inga beteendeförändringar.
Resten av den här artikeln beskriver hur du avgör om dessa säkerhetsförbättringar kan påverka programmets körningsbeteende. Den här artikeln innehåller också steg för att anpassa körningsbeteendet om du vill
Tillämplig programvara
Den här artikeln gäller följande programvara:
- .NET 8 och senare
- .NET Framework, alla versioner från och med säkerhetsuppdateringarna i juli 2024 och efterföljande uppdateringar
Endast när den körs på följande Windows Update-versioner:
- Windows 10 version 22H2 när KB5052077 är installerat
- Windows Server 2019, när KB5053594 installeras
- Windows Server 2016 när KB5053594 är installerad
Den här artikeln gäller inte för .NET Framework eller .NET som körs på Windows 11, Windows Server 2022 eller senare.
Den här artikeln gäller inte för .NET när den körs på andra plattformar än Windows.
Detaljerad beskrivning och konsekvensbeskrivning
Från och med de KB:ar för Windows-uppdateringen som nämns ovan har Microsoft bakåtporterat Win32 GetTempPath2-API :et till äldre marknadsversioner av Windows för att fungera som en säkrare ersättning för det äldre Win32 GetTempPath-API :et. Internt förlitar sig .NET Framework och .NET på dessa Win32-API:er för att tillhandahålla implementeringen av System.IO.Path.GetTempPath() metoden: Win32-API GetTempPath2:t är att föredra om det finns; och Win32-API GetTempPath:t används som reserv om GetTempPath2 inte finns.
Eftersom dessa KB gör det nya Win32-APIGetTempPath2:et tillgängligt på tillämpliga plattformar börjar .NET Framework och .NET använda GetTempPath2 när KB:erna har installerats.
Den primära beteendeförändringen är att anropare som körs som SYSTEM-identiteten observerar System.IO.Path.GetTempPath() att metoden returneras %WINDIR%\SystemTemp som standard, medan anropare som körs som något annat än SYSTEM-identiteten observerar att metoden fortsätter att returnera sitt befintliga värde.
Om ditt program uppfyller alla nedanstående kriterier kan du påverkas av den här ändringen:
- Programmet använder en runtime- och OS-plattform som anges under den tidigare rubriken "Tillämplig programvara". och
- Ditt program körs som SYSTEM-identitet. och
- Du ställer manuellt in miljövariabeln
%TMP%eller%TEMP%för att omdirigera temp-standardfilens plats. (Se avsnittet Anmärkningar i Win32GetTempPathAPI-dokumentation.)
Om du uppfyller alla dessa kriterier och sedan har installerat Windows KB:s kan du se att ditt program skriver till en annan temporär katalog än den som du avsåg.
Den här beteendeförändringen kan vara synlig via alla .NET Framework eller . NET-tillhandahållet API som så småningom förlitar sig på GetTempPath2. De vanligaste startpunkterna är:
- System.IO.Path.GetTempPath
- System.IO.Path.GetTempFileName
- System.IO.Directory.CreateTempSubdirectory
Detta är inte tänkt att vara en fullständig lista över metoder vars beteenden kan ändras när KB:erna har installerats.
Avgöra om ett program körs under systemidentiteten
Det finns flera olika metoder för att fastställa identiteten för ett program i .NET Framework eller .NET
IIS-baserade webbprogram
I IIS kallas SYSTEM-identiteten för "LOCALSYSTEM". I IIS-hanteraren (inetmgr.exe) går du till fliken Programpooler för att se alla appooler och deras associerade identiteter. Du kan också välja "Identitet" i listrutan Gruppera efter för att göra det enklare att se apppooler som körs som LOCALSYSTEM-identitet.
Skärmbilden nedan visar ett exempel på en apppool ("MyAppPool") som är konfigurerad för att köras som LOCALSYSTEM. Alla program som körs i den här appoolen körs som systemidentitet.
Du kan också komma åt den här informationen programmässigt från en upphöjd PowerShell-session med hjälp av skriptet nedan.
Import-Module IISAdministration
Get-IISAppPool | where {$_.ProcessModel.IdentityType -eq "LocalSystem"}
På en dator som konfigurerats med en MyAppPool-apppool på SYSTEM-nivå enligt skärmbilden ovan skriver det här PowerShell-skriptet ut följande, som visar att "MyAppPool" körs under SYSTEM-identiteten.
Name Status CLR Ver Pipeline Mode Start Mode
---- ------ ------- ------------- ----------
MyAppPool Started v4.0 Integrated OnDemand
Windows-tjänster
Om din .NET Framework eller . NET-baserat program är registrerat som en Windows-tjänst kan du använda Services Manager för att visa dess associerade identitet.
Från en upphöjd kommandotolk kör du services.msc. Användargränssnittet för Tjänsthanteraren visas.
Om kolumnen Logga in som visar "Lokalt system" för tjänstidentiteten körs tjänsten under systemidentiteten.
Du kan även köra frågor mot dessa data via PowerShell med hjälp av cmdleten Get-Service . Om du till exempel vill fråga efter den här informationen för en tjänst med namnet MyServiceanvänder du följande kommando.
(Get-Service MyService).UserName -ieq "LocalSystem"
Om tjänsten är registrerad för att köras under SYSTEM-identiteten skrivs detta ut True till konsolen.
Andra mekanismer
Verktyg som Aktivitetshanteraren (taskmgr.exe) eller Sysinternals Process Explorer kan också berätta om ett program körs under systemidentiteten.
I Aktivitetshanteraren använder du vyn Detaljer för att visa en lista över alla processer som körs i systemet. Leta sedan reda på den process du är intresserad av och titta på posten under kolumnen Användarnamn .
Om värdet för användarnamnet är "SYSTEM" körs processen under SYSTEM-identiteten.
Eller så letar du reda på den process som är av intresse i Sysinternals Processutforskaren och går in i vyn Egenskaper och tittar sedan på fältet Användare under fliken Bild .
Om användarvärdet är "NT AUTHORITY\SYSTEM" körs processen under SYSTEM-identiteten.
Ändra den tillfälliga sökvägen för processer på SYSTEM-nivå
PowerShell-skriptet nedan visar hur du skapar en ny katalog C:\NewSystemTemp\ och begränsar katalogåtkomsten till endast processer som körs under systemidentiteten. Försök inte ändra ACL:erna i en katalog som redan är fylld med filer.
Det här skriptet måste köras från en upphöjd PowerShell-session.
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
Du kan bekräfta att åtgärden lyckades genom att köra kommandot
icacls C:\NewSystemTemp\
Som ger följande utdata som visar framgång:
C:\NewSystemTemp\ NT AUTHORITY\SYSTEM:(OI)(CI)(F)
BUILTIN\Administrators:(OI)(CI)(F)
Successfully processed 1 files; Failed processing 0 files
När katalogen har skapats anger du miljövariabeln %SYSTEMTEMP% med omfång på systemnivå. Du kan ställa in detta via systemets kontrollpanelens användargränssnitt eller så kan du ställa in det programmatiskt via PowerShell:
[Environment]::SetEnvironmentVariable("SYSTEMTEMP", "C:\NewSystemTemp", [EnvironmentVariableTarget]::Machine)
Starta sedan om maskinen.
Om du ändrar miljövariabeln %SYSTEMTEMP%ändras inte returvärdet System.IO.Path.GetTempPath() för för .NET Framework- och .NET-program som körs som en annan identitet än SYSTEM. Dessa program fortsätter att följa samma lösningslogik som de alltid har gjort, inklusive att följa miljövariablerna %TMP% eller %TEMP% om de finns.
%TMP%
%TEMP% På samma sätt ändras inte returvärdet System.IO.Path.GetTempPath() för de program i .NET Framework och .NET som körs som SYSTEM-identitet.
För ytterligare information
Mer information om beteenden i .NET Framework och .NET finns i .NET-dokumentationen på Path.GetTempPath.
Mer information om det underliggande Windows OS-beteendet finns i Windows-dokumentationen om Win32 GetTempPath2-API:t.