Utgivningsdatum:25 februari 2025
Version:.NET 8 och senare.NET Framework, alla versioner
Sammanfattning
Microsoft har distribuerat säkerhetsförbättringar för de senaste versionerna av Windows. Dessa säkerhetsförbättringar ändrar hantering av tillfällig sökväg och kan göra att vissa .NET Framework- och .NET-API:er somSystem.IO.Path.GetTempPath()returnerar en annan plats efter att korrigeringsfilen har tillämpats.
Åtgärd krävs
Ingen åtgärd krävs för någon .NET Framework eller . NET-baserat program. Ditt program kommer automatiskt att dra nytta av alla säkerhetsförbättringar som gäller för din miljö. De flesta program ser inga beteendeförändringar.
Resten av den här artikeln beskriver hur du tar reda på om dessa säkerhetsförbättringar kan påverka programmets körningsbeteende. Den här artikeln innehåller också anvisningar för hur du anpassar 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 för juli 2024 och efterföljande uppdateringar
Endast när den körs i följande Windows Update-versioner:
-
Windows 10 version 22H2 när KB5052077 är installerad
-
Windows Server 2019 när KB5053594 har installerats
-
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å plattformar som inte är windowsbaserade.
Detaljerad beskrivning och effektpolicy
Från och med windows update-KB:erna som nämns ovan har Microsoft backporterat Win32 GetTempPath2 API till äldre versioner av Windows på marknaden för att fungera som en säkrare ersättning för det äldre GetTempPath API:t för Win32. Internt förlitar sig .NET Framework och .NET på dessa Win32-API:er för att tillhandahålla implementeringen av metoden System.IO.Path.GetTempPath() : Win32- GetTempPath2 -API:t föredras om den finns och Win32- GetTempPath -API:t används som reserv om GetTempPath2 inte finns.
Eftersom de här KB:erna gör det nya Win32- GetTempPath2 -API: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 uppringare som körs som SYSTEM-identitet observerar System.IO.Path.GetTempPath() metod returnerar %WINDIR%\SystemTemp som standard, medan uppringare som körs som något annat än SYSTEM-identiteten kommer att observera metoden fortsätter att returnera sitt befintliga värde.
Om ditt program uppfyller alla villkor nedan 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
-
Programmet körs som SYSTEM-identitet. och
-
Du ställer manuellt in variabeln %TMP% eller %TEMP% miljö för att omdirigera standardplatsen för temp-filen. (Se avsnittet Anmärkningar i dokumentationen för Win32 GetTempPath API.)
Om du uppfyller alla dessa villkor kan du när windows-KB:erna har installerats observera att programmet skriver till en annan tillfällig katalog än den katalog du avsåg.
Den här beteendeförändringen kan visas i alla .NET Framework eller . NET-api som så småningom förlitar sig på GetTempPath2. De vanligaste startpunkterna är:
Detta är inte avsett att vara en uttömmande lista över metoder vars beteenden kan ändras när KB:erna har installerats.
Avgöra om ett program körs under SYSTEM-identiteten
Det finns flera olika mekanismer för att fastställa identiteten för ett .NET Framework- eller .NET-program
IIS-baserade webbprogram
IIS refererar till SYSTEM-identiteten som "LOCALSYSTEM". I IIS-hanteraren (inetmgr.exe) går du till fliken Programpooler för att se alla apppooler 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 att köras som LOCALSYSTEM. Alla program som körs i den här apppoolen körs som SYSTEM-identitet.
Du kan också komma åt den här informationen programmässigt från en PowerShell-session med förhöjd behörighet med hjälp av skriptet nedan.
Import-Module IISAdministration Get-IISAppPool | where {$_.ProcessModel.IdentityType -eq "LocalSystem"}
På en dator som har konfigurerats med en apppool på SYSTEM-nivå som visas på skärmbilden ovan skriver powershell-skriptet ut följande och 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, du kan använda Tjänsthanteraren för att visa dess associerade identitet.
Kör services.mscfrån en upphöjd kommandotolk. Då visas användargränssnittet för Tjänsthanteraren.
Om kolumnen Logga in som innehåller "Lokalt system" för tjänstidentiteten körs tjänsten under SYSTEM-identiteten.
Du kan också fråga 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 Sant ut till konsolen.
Andra mekanismer
Verktyg som Aktivitetshanteraren (taskmgr.exe) eller Process Explorer för Sysinternals kan också ange om ett program körs under SYSTEM-identiteten.
I Aktivitetshanteraren använder du vyn Information för att visa alla processer som körs i systemet, letar sedan upp intresseprocessen och tittar på posten under kolumnen Användarnamn .
Om användarnamnsvärdet är "SYSTEM" körs processen under SYSTEM-identiteten.
Du kan också söka efter intresseprocessen i Sysinternals Process Explorer och ange vyn Egenskaper och sedan titta på fältet Användare under fliken Bild .
Om användarvärdet är "NT AUTHORITY\SYSTEM" körs processen under SYSTEM-identiteten.
Ändra temp-sökvägen för SYSTEM-processer
PowerShell-skriptet nedan visar hur du skapar en ny katalog C:\NewSystemTemp\ och begränsar katalogåtkomst till endast processer som körs under SYSTEM-identiteten. Försök inte ändra ACL:er för en katalog som redan är ifylld med filer.
Skriptet måste köras från en PowerShell-session med förhöjd behörighet.
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\
Vilket ger följande resultat 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 den %SYSTEMTEMP% miljövariabeln med omfattning på systemnivå. Du kan ange detta via användargränssnittet för system Kontrollpanelen, eller så kan du ställa in det programmässigt via PowerShell:
[Environment]::SetEnvironmentVariable("SYSTEMTEMP", "C:\NewSystemTemp", [EnvironmentVariableTarget]::Machine)
Starta sedan om datorn.
Om du ändrar miljövariabeln för %SYSTEMTEMP% ändras inte returvärdet för System.IO.Path.GetTempPath() för .NET Framework- och .NET-program som körs som en annan identitet än SYSTEM. Dessa program fortsätter att följa samma upplösningslogik som de alltid har, inklusive att följa de %TMP% - eller %TEMP% miljövariablerna om de finns.
Om du anger miljövariabeln %TMP% eller %TEMP% ändras inte heller returvärdet för System.IO.Path.GetTempPath() för .NET Framework- och .NET-program som körs som SYSTEM-identitet.
För ytterligare information
Mer information om .NET Framework och .NET-beteenden finns i .NET-dokumentationen på Path.GetTempPath.
Mer information om det underliggande operativsystemet i Windows finns i Windows-dokumentationen om Win32 GetTempPath2 API.
