Izlaides datums:2025. gada 25. februāris
Versija:.NET 8 vai jaunāka .NET Framework, visas versijas
Kopsavilkums
Microsoft ir jaunusi drošības uzlabojumus jaunākajām Windows versijām. Šie drošības uzlabojumi modificē temp ceļa apstrādi un var izraisīt noteiktus .NET Framework un .NET APISystem.IO.Path.GetTempPath()piemēram, lai pēc ielāpa lietošanas atgrieztu citu atrašanās vietu.
Nepieciešama rīcība
Nekādas darbības nav jāveic nevienam .NET Framework vai . NET lietojumprogramma. Jūsu lietojumprogrammai automātiski tiks tiesību izmantot visus ar jūsu vidi attiecināmos drošības uzlabojumus. Lielākā daļa lietojumprogrammu nepastās nekādas uzvedības izmaiņas.
Šī raksta pārējā daļā ir paskaidrots, kā noteikt, vai šie drošības uzlabojumi var ietekmēt programmas izpildlaika darbību. Šajā rakstā ir uzskaitītas arī darbības izpildlaika darbības pielāgošanai, ja nepieciešams
Attiecināmā programmatūra
Šis raksts attiecas uz šādu programmatūru:
-
.NET 8 un jaunākas versijas
-
.NET Framework 2024. gada jūlija drošības atjauninājumiem un turpmākajiem atjauninājumiem
Tikai tad, ja darbojas šādas Windows atjaunināšanas versijas:
-
Windows 10, versija 22H2, KB5052077 instalēta
-
Windows Server 2019, KB5053594 instalējot
-
Windows Server 2016, KB5053594 instalējot
Šis raksts neattiecas uz .NET Framework .NET, kas darbojas Windows 11, Windows Server 2022 vai jaunākā versijā.
Šis raksts neattiecas uz .NET, ja darbojas sistēmā, kas nav Windows platforma.
Detalizēts apraksts un ietekmes priekšraksts
Kā no Iepriekš minētā Windows atjauninājuma KBS, Microsoft ir atgriezusi Win32 GetTempPath2 API uz vecākām Windows tirgus versijām, lai darbojas kā drošāka vecāku Win32 GetTempPath API aizstājējs. Iekšēji .NET Framework un .NET izmanto šos Win32 API, lai nodrošinātu System.IO.Path.GetTempPath() metodes ieviešanu: Win32 GetTempPath2 API ir ieteicams, ja tāds pastāv; kā atkāpšanās tiek izmantots Win32 GetTempPath API, ja GetTempPath2 nepastāv.
Tā kā šīs KB padara jauno Win32 GetTempPath2 API pieejamu attiecīgajās platformās, .NET Framework un .NET sāks izmantot GetTempPath2, kad KB ir instalēta.
Primārās uzvedības izmaiņas ir tas, ka zvanītāji, kuri izmanto kā SYSTEM identitāti, pēc noklusējuma novērtēs System.IO.Path.GetTempPath() metodi, kas atgriež %WINDIR%\SystemTemp , savukārt zvanītāji, kuri darbojas kā citi, izņemot SYSTEM identitāti, konstatēs, ka metode turpinās atgriezt esošo vērtību.
Ja jūsu programma atbilst visiem tālāk norādītajiem kritērijiem, iespējams, šīs izmaiņas jūs ietekmēs.
-
Jūsu programma izmanto izpildlaika un OS platformu, kas norādīta zem iepriekšējā virsraksta "Attiecināmā programmatūra". un
-
Jūsu lietojumprogramma darbojas kā SYSTEM identitāte. un
-
Varat manuāli iestatīt datu %TMP% vai %TEMP% vides mainīgo, lai novirzītu standarta pagaidu faila atrašanās vietu. (Skatiet Win32 api dokumentācijasGetTempPath piezīmes.)
Ja atbilstiet visiem šiem kritērijiem, tad, kad Windows KB ir instalēta, iespējams, konstatēsiet, ka jūsu lietojumprogramma raksta citā direktorijā, kas nav paredzētajam direktorijam.
Šīs uzvedības izmaiņas var būt redzamas, izmantojot jebkuru .NET Framework vai . NET nodrošinātais API, kas ar laiku paļaujas uz GetTempPath2. Visbiežāk lietotie ieejas punkti ir:
Šis nav izsmeļošs to metožu saraksts, kuru darbība pēc KB instalēšanas var mainīties.
Noteikšana, vai lietojumprogramma darbojas zem SYSTEM identitātes
Ir vairāki atšķirīgi mehānismi, lai noteiktu lietojumprogrammas .NET Framework vai .NET
IIS tīmekļa lietojumprogrammas
IIS attiecas uz SISTĒMAS identitāti kā "LOCALSYSTEM". IIS pārvaldniekā (lietojumprogrammu inetmgr.exe) dodieties uz cilni Lietojumprogrammu drošība, lai skatītu visas lietojumprogrammu konfigurācijas un to saistītās identitātes. Varat arī atlasīt "Identitāte" nolaižamajā izvēlnē Grupēt pēc, lai būtu vieglāk skatīt lietojumprogrammu modeli, kas darbojas kā LOCALSYSTEM identitāte.
Tālāk redzamajā ekrānuzņēmumā redzams programmas pūla ("MyAppPool") piemērs, kas ir konfigurēts palaišanai kā LOCALSYSTEM. Visas lietojumprogrammas, kas darbojas šajā lietojumprogrammu pūlā, darbosies kā SYSTEM identitāte.
Šai informācijai varat piekļūt arī programmiski no priviliģētas PowerShell sesijas, izmantojot tālāk esošo skriptu.
Import-Module IISAdministration Get-IISAppPool | where {$_.ProcessModel.IdentityType -eq "LocalSystem"}
Datorā, kas konfigurēts ar SYSTEM līmeņa "MyAppPool" programmas pūlu, kā parādīts iepriekš ekrānuzņēmumā, šis PowerShell skripts drukā šo tekstu, parādot, ka "MyAppPool" darbojas ar SYSTEM identitāti.
Name Status CLR Ver Pipeline Mode Start Mode ---- ------ ------- ------------- ---------- MyAppPool Started v4.0 Integrated OnDemand
Windows pakalpojumi
Ja jūsu .NET Framework vai . NET lietojumprogramma ir reģistrēta kā Windows pakalpojums, varat izmantot pakalpojumu pārvaldnieku, lai skatītu tā saistīto identitāti.
Priviliģētā komandu uzvednē palaidiet services.msc. Pakalpojumu pārvaldnieka LIETOTĀJA interfeiss tiek rādīts.
Ja kolonnā Pieteikties kā ir norādīts "Lokālā sistēma" pakalpojuma identitātei, pakalpojums darbojas ar SYSTEM identitāti.
Varat arī veikt vaicājumus ar datiem, izmantojot PowerShell, izmantojot Get-Service cmdlet. Piemēram, lai šai informācijai izveidotu vaicājumu pakalpojumam ar nosaukumu MyService, izmantojiet tālāk norādīto komandu.
(Get-Service MyService).UserName -ieq "LocalSystem"
Ja pakalpojums ir reģistrēts palaišanai ar system identitāti, konsolē tiek drukāts True.
Citi mehānismi
Rīkus, piemēram, Task Manager (taskmgr.exe) vai Sysinternals Process Explorer , var arī noteikt, vai lietojumprogramma darbojas ar SYSTEM identitāti.
Sadaļā Uzdevumu pārvaldnieks izmantojiet skatu Detalizēti, lai uzskaitītu visus sistēmā izpildītos procesus, pēc tam atrodiet vajadzīgo procesu un skatiet ierakstu kolonnā Lietotājvārds .
Ja lietotājvārda vērtība lasa "SYSTEM", process darbojas ar SYSTEM identitāti.
Vai arī sysinternals procesu pārlūkā atrodiet vajadzīgo procesu un ievadiet rekvizītu skatu, pēc tam cilnē Attēls aplūkojiet lauku Lietotājs.
Ja lietotāja vērtība lasa "NT AUTHORITY\SYSTEM", šis process darbojas ar SYSTEM identitāti.
System līmeņa procesu pagaidu ceļa maiņa
Tālāk redzamais PowerShell skripts parāda, kā izveidot jaunu direktorija C:\NewSystemTemp\ un ierobežot direktorija piekļuvi tikai procesiem, kas darbojas ar SYSTEM identitāti. Nemēģiniet mainīt jau aizpildīta direktorija ACL ar failiem.
Šis skripts ir jāpalaiž priviliģētā PowerShell sesijā.
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
Izpildot komandu, varat apstiprināt, ka šī darbība bijusi veiksmīga
icacls C:\NewSystemTemp\
Tā izveidos šādu izvadi, parādot panākumus:
C:\NewSystemTemp\ NT AUTHORITY\SYSTEM:(OI)(CI)(F) BUILTIN\Administrators:(OI)(CI)(F) Successfully processed 1 files; Failed processing 0 files
Kad direktorijs ir izveidots, iestatiet mainīgo %SYSTEMTEMP% vidi ar sistēmas līmeņa tvērumu. Varat to iestatīt, izmantojot sistēmas interfeisa vadības panelis, vai varat to iestatīt programmiski, izmantojot PowerShell:
[Environment]::SetEnvironmentVariable("SYSTEMTEMP", "C:\NewSystemTemp", [EnvironmentVariableTarget]::Machine)
Pēc tam restartējiet datoru.
Mainot %SYSTEMTEMP% vides mainīgo, netiek mainīta atgriezto System.IO.Path.GetTempPath() .NET Framework un .NET lietojumprogrammām, kas darbojas kā identitāte, kas nav SYSTEM. Šīm lietojumprogrammām joprojām būs vienādas izšķirtspējas loģika, kas tiem vienmēr ir, tostarp saglabāt %TMP% vai %TEMP% vides mainīgos.
Līdzīgi arī %TMP% vai %TEMP% vides mainīgā iestatīšana nemainīs atgriezto System.IO.Path.GetTempPath() vērtību .NET Framework un .NET lietojumprogrammām, kas darbojas kā SYSTEM identitāte.
Lai iegūtu papildinformāciju
Papildinformāciju par .NET Framework .NET darbību skatiet .NET dokumentācijā, kas pieejama šeit: Path.GetTempPath.
Papildinformāciju par pamatā esošo Windows OS darbību skatiet Windows dokumentācijā Win32 GetTempPath2 API.
