Bezpieczna implementacja MOR

Podsumowanie

• Zachowanie MorLocka, poprawka 2

Ostatnia aktualizacja

• Sierpień 2020

Odnosi się do

• Windows 10

• Producenci OEM i dostawcy systemu BIOS, którzy chcą obsługiwać funkcję Credential Guard systemu Windows 10.

Oficjalne specyfikacje

• Specyfikacje interfejsu UEFI

• PC Client Work Group Platform Reset Attack Mitigation Specification, Version 1.10 (Pobierz PDF)

Zalecane tematy

• Wpis na blogu: Jak chronić BitLocker przed atakami typu cold boot (i innymi zagrożeniami)

• Oficjalny dokument: zwiedzanie poza BIOS z obsługą UEFI TPM2 w EDKII

• Chroń pochodne poświadczenia domeny przy użyciu funkcji Credential Guard

Przegląd

W tym temacie opisano zachowanie i użycie zmiennej MemoryOverwriteRequestControlLock UEFI w wersji 2.

Aby zapobiec zaawansowanym atakom pamięci, istniejące środki zaradcze zabezpieczeń systemu BIOS MemoryOverwriteRequestControl są ulepszone w celu zapewnienia obsługi blokady w celu obrony przed nowymi zagrożeniami. Model zagrożenia został rozszerzony tak, aby zawierał jądro systemu operacyjnego hosta jako przeciwnika, w związku z czym usługi ACPI i UEFI Runtime Services wykonywane na poziomie uprawnień jądra nie są zaufane. Podobnie jak w przypadku implementacji bezpiecznego rozruchu, MorLock należy zaimplementować w uprzywilejowanym kontekście wykonywania oprogramowania układowego, którego nie można manipulować przez jądro systemu operacyjnego hosta (na przykład Tryb zarządzania systemem, TrustZone, BMC itd.). Interfejs jest oparty na usługach zmiennych UEFI, które są opisane w specyfikacji UEFI w wersji 2.5, sekcja 7.2 o nazwie "Usługi zmiennych".

Takie środki zaradcze o nazwie MorLock muszą być implementowane we wszystkich nowych systemach i nie tylko w przypadku systemów z modułami trusted platform. Poprawka 2 dodaje nową funkcję, odblokowywanie, aby wyeliminować problemy z wydajnością rozruchu, szczególnie w przypadku dużych systemów pamięci.

Jeśli chodzi o metodę kontrolną ACPI _DSM do ustawienia stanu bitu MOR (zgodnie z opisem w Sekcji 6 Specyfikacji Ograniczania Ryzyka Ataków Resetowania Platformy Grupy Roboczej Klientów PC, Wersja 1.10 (plik PDF do pobrania)), zalecamy usunięcie tej metody _DSM z nowoczesnych implementacji BIOS.

Jeśli jednak system BIOS implementuje tę metodę _DSM, musi przestrzegać stanu MorLock. Jeśli morLock jest zablokowany, z lub bez klucza, ta metoda _DSM musi nie zmienić MOR i zwrócić wartość 1 odpowiadającą "Błąd ogólny". Nie zdefiniowano mechanizmu ACPI w celu odblokowania poprawki MorLock 2.

Należy pamiętać, że system Windows nie wywołał bezpośrednio tej metody _DSM od systemu Windows 7 i uważa, że jest przestarzały. Niektóre systemy BIOS pośrednio wywołują tę metodę _DSM, gdy system Windows wywołuje _PTS ACPI jako implementację MOR Auto Detection of Clean Shutdown (zgodnie z opisem w sekcji 2.3 PC Client Work Group Platform Reset Attack Mitigation Specification, Wersja 1.10 (plik PDF download)).

Implementacja _PTS ACPI automatycznego wykrywania MOR ma braki w zabezpieczeniach i nie należy jej używać.

KontrolaZablokowaniaŻądaniaNadpisywaniaPamięci

BIOS systemowy zawierający ulepszone środki zaradcze, tworzy tę zmienną UEFI podczas rozruchu we wczesnej fazie.

VendorGuid:{BB983CCF-151D-40E1-A07B-4A17BE168292}

Nazwa:MemoryOverwriteRequestControlLock

Atrybuty: NV+BS+RT

GetVariable wartość w parametrze danych : 0x0 (odblokowane); 0x1 (zablokowane bez klucza); 0x2 (zablokowane za pomocą klucza)

SetVariable wartość w parametrze Data: 0x0 (odblokowane); 0x1 (zablokowane)

Blokowanie za pomocą funkcji SetVariable

Podczas każdego rozruchu system BIOS ustawia MemoryOverwriteRequestControlLock na wartość jednego bajtu 0x00 (oznaczającą odblokowanie) przed fazą wyboru urządzenia rozruchowego (DRIVER####, SYSPREP####, BOOT####, *RECOVERY*, ...). W przypadku MemoryOverwriteRequestControlLock (i MemoryOverwriteRequestControl) system BIOS uniemożliwia usunięcie zmiennej, a atrybuty muszą być przypisane do NV+BS+RT.

Gdy funkcja SetVariable dla MemoryOverwriteRequestControlLock jest najpierw wywoływana przez przekazanie prawidłowej wartości innej niż zero w Dane, tryb dostępu dla obu MemoryOverwriteRequestControlLock i MemoryOverwriteRequestControl jest zmieniany na tylko do odczytu, co oznacza, że są zablokowane.

Implementacje Rewizji 1 akceptują tylko jeden bajt 0x00 lub 0x01 dla MemoryOverwriteRequestControlLock.

Poprawka 2 dodatkowo akceptuje wartość 8-bajtową, która reprezentuje wspólny klucz tajny. Jeśli w SetVariable określona zostanie jakakolwiek inna wartość, wywołanie zakończy się niepowodzeniem ze statusem EFI_INVALID_PARAMETER. Aby wygenerować ten klucz, użyj źródła entropii wysokiej jakości, takiego jak moduł Trusted Platform Module lub generator liczb losowych sprzętu.

Po ustawieniu klucza zarówno obiekt wywołujący, jak i firmware powinny zapisywać kopie tego klucza w chronionej lokalizacji zapewniającej poufność, takiej jak SMRAM na IA32/X64 lub procesor usługi z chronionym magazynem.

Pobieranie stanu systemu

W rewizji 2, gdy zmienne MemoryOverwriteRequestControlLock i MemoryOverwriteRequestControl są zablokowane, wywołania SetVariable (dla tych zmiennych) są najpierw sprawdzane względem zarejestrowanego klucza przy użyciu algorytmu w czasie stałym. Jeśli oba klucze są obecne i zgodne, zmienne przechodzą z powrotem do stanu odblokowania. Po pierwszej próbie lub jeśli nie zarejestrowano klucza, kolejne próby ustawienia tej zmiennej kończą się niepowodzeniem z EFI_ACCESS_DENIED, aby zapobiec atakom siłowym. W takim przypadku ponowne uruchomienie systemu jest jedynym sposobem odblokowania zmiennych.

System operacyjny wykrywa obecność MemoryOverwriteRequestControlLock elementu i jego stan przez wywołanie metody GetVariable. Następnie system może zablokować bieżącą wartość MemoryOverwriteRequestControl , ustawiając MemoryOverwriteRequestControlLock wartość na 0x1. Alternatywnie może określić klucz umożliwiający odblokowanie w przyszłości po bezpiecznym przeczyszczaniu danych tajnych z pamięci.

Wywołanie GetVariable dla MemoryOverwriteRequestControlLock zwraca 0x0, 0x1 lub 0x2 w celu wskazania odblokowany, zablokowany bez klucza lub zablokowany z kluczem.

Ustawienie MemoryOverwriteRequestControlLock nie powoduje zapisania do pamięci flash (po prostu zmienia stan wewnętrznej blokady). Pobranie zmiennej zwraca stan wewnętrzny i nigdy nie ujawnia klucza.

Przykładowe użycie przez system operacyjny:

if (gSecretsInMemory)
{
    char data = 0x11;
    SetVariable(MemoryOverwriteRequestControl, sizeof(data), &data);
}

// check presence
status = GetVariable(MemoryOverwriteRequestControlLock, &value);  

if (SUCCESS(status))
{
    // first attempt to lock and establish a key
    // note both MOR and MorLock are locked if successful

    GetRNG(8, keyPtr);
    status = SetVariable(MemoryOverwriteRequestControlLock, 8, keyPtr);

    if (status != EFI_SUCCESS)
    {
        // fallback to revision 1 behavior
        char data = 0x01;
        status = SetVariable(MemoryOverwriteRequestControlLock, 1, &data);
        if (status != EFI_SUCCESS) { // log error, warn user }
    }
}
else
{
    // warn user about potentially unsafe system
}

// put secrets in memory

// … time passes …

// remove secrets from memory, flush caches

SetVariable(MemoryOverwriteRequestControlLock, 8, keyPtr);

Przepływ implementacji MorLock

Te schematy blokowe pokazują oczekiwane zachowanie implementacji:

Inicjalizacja

Przepływ SetVariable

Odblokowany przepływ stanu dla zmiennej SetVariable

Zablokowany przepływ stanu dla zmiennej SetVariable

Przepływ dla GetVariable

Zobacz także

wymagania ueFI dotyczące wszystkich wersji systemu Windows na platformach SoC

PC Client Work Group Platform Reset Attack Mitigation Specification, Version 1.10 (Pobierz PDF)

Ochrona funkcji BitLocker przed atakami typu 'Cold Attack' (i innymi zagrożeniami)

Podróż poza BIOS z obsługą TPM2 w interfejsie UEFI w EDKII

Chroń pochodne poświadczenia domeny przy użyciu funkcji Credential Guard

Specyfikacje interfejsu UEFI