Not
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Windows 10 introducerade en ny säkerhetsfunktion med namnet VIRTUAL Secure Mode (VSM). VSM utnyttjar Hyper-V Hypervisor och SLAT (Second Level Address Translation) för att skapa en uppsättning lägen som kallas virtuella förtroendenivåer (VTL). Den här nya programvaruarkitekturen skapar en säkerhetsgräns för att förhindra att processer som körs i en VTL kommer åt minnet för en annan VTL. Fördelen med den här isoleringen omfattar ytterligare åtgärder från kernel-sårbarheter samtidigt som du skyddar tillgångar som lösenordshashvärden och Kerberos-nycklar.
Diagram 1 visar den traditionella modellen för kernelläge och användarlägeskod som körs i CPU-ring 0 respektive ring 3. I den här nya modellen körs koden som körs i den traditionella modellen i VTL0 och den kan inte komma åt den högre privilegierade VTL1, där IUM-koden (Secure Kernel and Isolated User Mode) kör kod. VTL:er är hierarkiska, vilket innebär att all kod som körs i VTL1 är mer privilegierad än kod som körs i VTL0.
VTL-isoleringen skapas av Hyper-V Hypervisor som tilldelar minne vid start med hjälp av SLAT (Second Level Address Translation). Det fortsätter dynamiskt när systemet körs, vilket skyddar minnet som den säkra kerneln anger behöver skydd mot VTL0 eftersom den kommer att användas för att innehålla hemligheter. När separata minnesblock allokeras för de två VTL:erna skapas en säker körningsmiljö för VTL1 genom att tilldela exklusiva minnesblock till VTL1 och VTL0 med rätt åtkomstbehörigheter.
diagram 1 – IUM-arkitektur
Trustlets
Trustlets (även kallade betrodda processer, säkra processer eller IUM-processer) är program som körs som IUM-processer i VSM. De slutför systemanrop genom att samla dem till Windows-kerneln som körs i VTL0 ring 0. VSM skapar en liten körningsmiljö som innehåller den lilla säkra kernelkörningen i VTL1 (isolerad från kerneln och drivrutinerna som körs i VTL0). Den tydliga säkerhetsförmånen är isolering av trustlet-användarlägessidor i VTL1 från drivrutiner som körs i VTL0-kerneln. Även om kernelläget för VTL0 komprometteras av skadlig kod har det inte åtkomst till IUM-processsidorna.
Med VSM aktiverat körs LSASS-miljön (Local Security Authority) som en trustlet. LSASS hanterar den lokala systemprincipen, användarautentisering och granskning vid hantering av känsliga säkerhetsdata, till exempel lösenordshashvärden och Kerberos-nycklar. För att utnyttja säkerhetsfördelarna med VSM körs en trustlet med namnet LSAISO.exe (LSA Isolated) i VTL1 och kommunicerar med LSASS.exe som körs i VTL0 via en RPC-kanal. LSAISO-hemligheter krypteras innan de skickas till LSASS som körs i VSM-normalt läge och sidorna i LSAISO skyddas från skadlig kod som körs i VTL0.
Diagram 2 – LSASS Trustlet Design
Konsekvenser för isolerat användarläge (IUM)
Det går inte att ansluta till en IUM-process, vilket hämmar möjligheten att felsöka VTL1-kod. Detta inkluderar felsökning efter döden av minnesdumpar och anslutning av felsökningsverktygen för felsökning i realtid. Den innehåller också försök av privilegierade konton eller kerneldrivrutiner att läsa in en DLL i en IUM-process, mata in en tråd eller leverera en APC i användarläge. Sådana försök kan leda till destabilisering av hela systemet. Windows-API:er som skulle äventyra säkerheten för en Trustlet kan misslyckas på oväntade sätt. Om du till exempel läser in en DLL i en Trustlet blir den tillgänglig i VTL0 men inte VTL1. QueueUserApc kan misslyckas tyst om måltråden finns i en Trustlet. Andra API:er, till exempel CreateRemoteThread, VirtualAllocEx och Read/WriteProcessMemory fungerar inte heller som förväntat när de används mot Trustlets.
Använd exempelkoden nedan för att förhindra att anropa funktioner som försöker koppla eller mata in kod i en IUM-process. Detta inkluderar kerneldrivrutiner som köar API:er för körning av kod i en trustlet.
Anmärkningar
Om returstatusen för IsSecureProcess lyckas undersöker du parametern SecureProcess _Out_ för att avgöra om processen är en IUM-process. IUM-processer markeras av systemet som "säkra processer". Ett booleskt resultat av TRUE innebär att målprocessen är av typen IUM.
NTSTATUS
IsSecureProcess(
_In_ HANDLE ProcessHandle,
_Out_ BOOLEAN *SecureProcess
)
{
NTSTATUS status;
// definition included in ntddk.h
PROCESS_EXTENDED_BASIC_INFORMATION extendedInfo = {0};
PAGED_CODE();
extendedInfo.Size = sizeof(extendedInfo);
// Query for the process information
status = ZwQueryInformationProcess(
ProcessHandle, ProcessBasicInformation, &extendedInfo,
sizeof(extendedInfo), NULL);
if (NT_SUCCESS(status)) {
*SecureProcess = (BOOLEAN)(extendedInfo.IsSecureProcess != 0);
}
return status;
}
WDK för Windows 10, "Windows Driver Kit – Windows 10.0.15063.0", innehåller den nödvändiga definitionen av PROCESS_EXTENDED_BASIC_INFORMATION struktur. Den uppdaterade versionen av strukturen definieras i ntddk.h med det nya fältet IsSecureProcess.
typedef struct _PROCESS_EXTENDED_BASIC_INFORMATION {
SIZE_T Size; // Ignored as input, written with structure size on output
PROCESS_BASIC_INFORMATION BasicInfo;
union {
ULONG Flags;
struct {
ULONG IsProtectedProcess : 1;
ULONG IsWow64Process : 1;
ULONG IsProcessDeleting : 1;
ULONG IsCrossSessionCreate : 1;
ULONG IsFrozen : 1;
ULONG IsBackground : 1;
ULONG IsStronglyNamed : 1;
ULONG IsSecureProcess : 1;
ULONG IsSubsystemProcess : 1;
ULONG SpareBits : 23;
} DUMMYSTRUCTNAME;
} DUMMYUNIONNAME;
} PROCESS_EXTENDED_BASIC_INFORMATION, *PPROCESS_EXTENDED_BASIC_INFORMATION;