Redukcja powierzchni ataku na oprogramowanie układowe (FASR)

W październiku 2019 r. firma Microsoft ściśle współpracowała z naszymi partnerami OEM i w dziedzinie technologii krzemowej, aby uruchomić komputery z zabezpieczonym rdzeniem. Te urządzenia zawierają głęboko zintegrowany sprzęt, oprogramowanie układowe i oprogramowanie, aby zapewnić zwiększone bezpieczeństwo urządzeń, tożsamości i danych. Jednym z podstawowych filarów zabezpieczeń komputerów z zabezpieczeniem rdzeni jest wspieranie ochrony oprogramowania układowego urządzeń. Podstawową funkcją sprzętową wymaganą do spełnienia tego filaru jest Dynamiczny element zaufania do pomiaru (D-RTM). Niestety, obecnie niewiele urządzeń oferuje D-RTM z powodu zależności od podstawowego układu scalonego niezbędnego do obsługi tej funkcji, co utrudnia nasze starania o podniesienie i utrzymanie wysokiego standardu bezpieczeństwa dla wszystkich urządzeń z systemem Windows.

Można zrobić więcej, aby zwiększyć poziom zabezpieczeń wszystkich urządzeń z systemem Windows, w tym bez D-RTM. Firma Microsoft współpracuje z partnerami, aby przezwyciężyć problemy ze zgodnością, które uniemożliwiły stosowanie ochrony pamięci w oprogramowaniu układowym UEFI, opracowując zestaw rozszerzeń zabezpieczeń SMM typu open source, aby zapewnić dodatkową elastyczność używania przez producenta OEM.

Aby odzwierciedlić to zobowiązanie do zabezpieczeń oprogramowania układowego, zidentyfikowaliśmy nowe podejście w celu zapewnienia, że urządzenia mogą spełniać wymagania dotyczące ochrony oprogramowania układowego komputerów z zabezpieczonymi rdzeniami.

Omówienie usługi FASR

W przypadku komputerów typu Secured-core, które nie posiadają sprzętowych funkcji D-RTM, musimy określić niewielki zestaw komponentów oprogramowania układowego, które oferują ograniczoną powierzchnię ataków i mogą być uwierzytelnione w systemie operacyjnym. Takie podejście jest nazywane zmniejszeniem obszaru ataków oprogramowania układowego (FASR). Aby oprogramowanie układowe oparte na usłudze FASR było skalowane między komputerami z różnych dostawców, należy zdefiniować nowe podejście do procesu rozruchu oprogramowania układowego.

Usługa FASR obsługuje dwie ścieżki rozruchu:

1. Certyfikowana ścieżka rozruchowa:

   • Tylko kod zaufany, podpisany i zintegrowany przez firmę Microsoft może być wykonywany.

   • Manipulowanie ścieżką rozruchu jest wykrywalne przez system operacyjny.

   Na poniższej ilustracji przedstawiono przepływ rozruchu FASR S-RTM na certyfikowanej ścieżce rozruchowej. Ta ścieżka rozruchowa pomaga zapobiec wykonywaniu nieoczekiwanego kodu oprogramowania układowego platformy. Jednak korzysta ona z niektórych danych specyficznych dla platformy dostarczonych przez niestandardową ścieżkę rozruchową. Na poniższym diagramie przedstawiono przepływ rozruchu FASR na certyfikowanej ścieżce rozruchowej.

   

2. Niestandardowa ścieżka rozruchowa: Cały kod oprogramowania układowego platformy może zostać wykonany. Informacje istotne dla rozruchu, specyficzne dla danego producenta OEM lub platformy, są przekształcane na dane związane z niestandardową ścieżką rozruchową i wykorzystywane przez certyfikowaną ścieżkę rozruchową do właściwego skonfigurowania systemu w tej ścieżce. Na poniższym diagramie przedstawiono przepływ rozruchu FASR na niestandardowej ścieżce rozruchowej.

   

   Urządzenie FASR przystosowane do zgodności z komputerami typu Secured-core PC domyślnie uruchamia się zgodnie z certyfikowaną ścieżką rozruchową, chyba że wczesny etap procesu uruchamiania oprogramowania układowego zostanie zakłócony przez zdarzenie, które powoduje przełączenie na niestandardową ścieżkę rozruchową. Przykładami takich zdarzeń są aktualizacja oprogramowania układowego, użytkownik zażądał dostępu do interfejsu oprogramowania układowego lub użytkownik zdecydował się wyłączyć komputer z zabezpieczonym rdzeniem, co oznacza, że zawsze będą się uruchamiać na niestandardowej ścieżce rozruchowej do momentu ponownego włączenia.

   Rozruch niestandardowy może być używany do uruchamiania dowolnego systemu operacyjnego lub oprogramowania innej firmy, wspieranego przez oprogramowanie układowe platformy na urządzeniu obsługującym FASR, ale system Windows nie rozpozna rozruchu na niestandardowej ścieżce jako spełniającego wymogi PC z zabezpieczeniem rdzenia.

Aby lepiej zrozumieć technologie zabezpieczeń związane z faSR, chcielibyśmy udostępnić krótki przegląd procesu rozruchu systemu Windows.

Proces rozruchu systemu Windows

Podstawa zaufania

Początkowe wykonywanie oprogramowania układowego na nowoczesnym komputerze odbywa się zgodnie z procesem rozruchowym, w którym początkowy zestaw kodu ładuje inny kod, a poziom funkcjonalności rozwija się w miarę postępu rozruchu. Każdy zestaw kodu weryfikuje następny zestaw kodu tworzącego łańcuch zaufania. Gdy oprogramowanie układowe UEFI zyskuje kontrolę, przestrzega standardu Bezpiecznego rozruchu, weryfikując podpisy oprogramowania, aby kontynuować łańcuch zaufania do systemu operacyjnego. Następnie program rozruchowy Windows kontynuuje łańcuch zaufania z Zaufanym Rozruchem, który weryfikuje wszystkie inne składniki systemu operacyjnego w procesie uruchamiania przed ich załadowaniem.

Ogólnie rzecz biorąc, osoby atakujące starają się jak najszybciej uzyskać kontrolę w procesie rozruchu przed włączeniem funkcji zabezpieczeń i blokad, które pomagają chronić system. Gdy system zostanie wyprowadzony z trybu resetu, początkowy zestaw wykonywanego kodu musi być oparty na zaufaniu. Technologia weryfikacji sprzętu, która pełni rolę w celu przeprowadzenia tej wczesnej weryfikacji kodu, jest nazywana elementem głównym zaufania. Chociaż dokładne szczegóły różnią się w zależności od dostawcy sprzętu, wszystkie korzenie zaufania są zazwyczaj zakorzenione w niezmiennym sprzęcie lub ROM-ach w SOC.

Mierzony rozruch

Bezpieczny rozruch zakotwiczony w zaufanym rdzeniu pomaga zapewnić, że podpis cyfrowy całego oprogramowania układowego zostanie zweryfikowany; oprócz tego pożądane jest prowadzenie dokładnego rejestru, jakie dokładnie oprogramowanie układowe zostało wykonane. Program zgodności sprzętu systemu Windows wymaga, aby wszystkie komputery z systemami Windows 10 i Windows 11 zawierały mikroukład o nazwie Trusted Platform Module (TPM). Moduł TPM zawiera lokalizacje pamięci nazywane rejestrami konfiguracji platformy (PCR). Każdy PCR zawiera skrót dla typu kodu i/lub danych załadowanych podczas rozruchu, takich jak kod oprogramowania układowego na nieulotnym urządzeniu magazynującym (na przykład flash SPI), opcje ROM z urządzeń PCI lub program ładujący system operacyjny. Rozmiar wartości, którą można przechowywać w PCR, zależy od rozmiaru skrótu obsługiwanego algorytmu haszującego. Na przykład sha-1 PCR może przechowywać 20 bajtów, podczas gdy SHA-2 PCR może przechowywać 32 bajty. Wiele rejestrów PCR powiązanych z tym samym algorytmem haszowania nazywane jest bankiem. Specyfikacja profilu TPM klienta TCG określa konieczność włączenia co najmniej jednego banku PCR z 24 rejestrami.

W przypadku obecności modułu TPM każdy składnik oprogramowania układowego może również aktualizować lub rozszerzać odpowiedni PCR, gdy nowy kod i dane są ładowane w procesie rozruchu. Proces rozszerzania aktualizuje wartość PCR jako dane wyjściowe z algorytmu skrótu przy użyciu bieżącej wartości PCR łączonej z nowym kodem lub argumentem danych jako danymi wejściowymi. Dzięki temu, po zakończeniu procesu rozruchu można sprawdzić, co zostało wykonane. Dzięki temu oprogramowanie w systemie operacyjnym może zrozumieć, czy proces rozruchu różnił się od poprzednich rozruchów. W środowisku o wysokim poziomie bezpieczeństwa system operacyjny może być informowany o dokładnym zestawie pomiarów kodu oczekiwanych w niektórych rejestrach PCR w celu wykrycia wykonywania nieoczekiwanego kodu oprogramowania układowego. Ponieważ pierwsze 16 PCR w banku można zresetować tylko przez zresetowanie całego modułu TPM, są uznawane za zaufane i preferowane miejsce przechowywania ważnych pomiarów w module TPM.

Podstawa zaufania do pomiaru

Po zbadaniu roli korzenia zaufania oraz sposobu użycia mierzonego rozruchu przyjrzymy się dwóm typowym podejściom do ustanawiania korzenia zaufania do przekazywania łańcucha pomiarów do TPM: statycznego i dynamicznego.

Statyczne korzenie zaufania dla pomiaru (S-RTM) ustanawiają zaufanie podczas resetu systemu i wymagają zachowania tego zaufania w całym procesie rozruchu. Jeśli zaufanie zostanie naruszone w dowolnym momencie procesu rozruchu, jest to nieodwracalne do czasu zresetowania systemu. Na poniższym diagramie przedstawiono sposób użycia protokołu S-RTM na certyfikowanej ścieżce rozruchowej.

Natomiast Dynamiczne Źródło Zaufania dla Pomiary (D-RTM) ufa tylko niewielkiej części kodu oprogramowania układowego inicjacji początkowej układu scalonego oraz agentowi sprzętowemu, który jest używany do ponownego ustanawiania zaufania dynamicznie podczas rozruchu. System może początkowo uruchomić niezaufany kod oprogramowania układowego, ale wkrótce po uruchomieniu powróci do zaufanego stanu, przejmując kontrolę nad wszystkimi procesorami CPU i zmuszając je do ściągnięcia dobrze znanej i mierzonej ścieżki. Poniższy diagram zawiera omówienie tradycyjnego procesu D-RTM.

Istnieje kompromis między S-RTM i D-RTM. Protokół S-RTM nie wymaga specjalnych możliwości sprzętowych, ale wymaga, aby oprogramowanie lepiej uwzględniało kod wykonywany podczas całego rozruchu. D-RTM wymaga specjalnych możliwości sprzętowych, ale umożliwia dynamiczne uruchamianie oprogramowania w zaufanym stanie w okresie istnienia systemu.

Komputery z zabezpieczonym jądrem systemu Windows używały protokołu D-RTM w bezpiecznym uruchomieniu, aby umożliwić szerokiej gamie producentów elastyczne wdrażanie unikalnych funkcji i doświadczeń w oprogramowaniu układowym, jednocześnie pomagając zapewnić, że system może osiągnąć zaufany i zmierzony stan akceptowalny dla hostowania bezpiecznego środowiska systemu operacyjnego. Zdarzenie uruchomienia D-RTM służy do przywrócenia zaufania w nieznanym środowisku przed załadowaniem bezpiecznego jądra. Na poniższym diagramie przedstawiono zdarzenie uruchamiania D-RTM w celu ponownego ustanowienia znanego środowiska systemowego.

W przeszłości protokół S-RTM można zaimplementować w większej ogóle urządzenia ze względu na brak zależności od specjalnych możliwości sprzętowych w celu zweryfikowania stanu zabezpieczeń systemu, ale system operacyjny nie miał niezawodnej metody, aby potwierdzić, że może ufać pomiarom zgłoszonym na danym urządzeniu z systemem Windows przy użyciu protokołu S-RTM.

Ulepszenia zabezpieczeń oprogramowania układowego

Minimalizowanie składników oprogramowania układowego w ścieżce rozruchowej systemu operacyjnego

Jednym ze sposobów zaufania pomiarom S-RTM jest zmniejszenie składników oprogramowania układowego, które mogą być wykonywane do minimalnego zestawu. Jeśli wszystkie urządzenia korzystające z protokołu S-RTM używały tego samego zestawu składników oprogramowania układowego, system operacyjny musi ufać tylko jednemu zestawowi oczekiwanych wartości PCR dla tych znanych i zaufanych składników. W przypadku tego podejścia opartego na protokole SRTM można uznać, że urządzenie spełnia wymaganie ochrony oprogramowania układowego komputerów zabezpieczonych rdzeni, gdy zestaw oprogramowania układowego rozruchu jest weryfikowany tylko pod kątem oprogramowania podpisanego przez firmę Microsoft, które można potwierdzić przez system Windows. Aby lepiej zrozumieć, jak te składniki oprogramowania układowego różnią się od tych w normalnym rozruchu komputera, przeanalizujmy proces rozruchu przed i po.

Ze względu na elastyczność i bogaty zestaw funkcji oferowanych przez nowoczesne oprogramowanie układowe komputera, kod wykonywany przed systemem operacyjnym powoduje zwiększenie obszaru ataków. Na poniższym diagramie przedstawiono przykład tradycyjnego przepływu rozruchu S-RTM.

Główne obowiązki oprogramowania układowego podczas rozruchu można znacznie uprościć:

• Specyficzne dla platformy: funkcjonalność, która ma zastosowanie tylko do konkretnego projektu sprzętowego platformy.

• Niespecyficzne dla platformy: funkcjonalność, która jest standardem branżowym i wspólna dla innego sprzętu.

Stosunkowo mały podzbiór nowoczesnego oprogramowania układowego jest zwykle specyficzny dla platformy. Większość kodu infrastruktury oprogramowania układowego, który wykonuje typowe zadania, takie jak przydzielanie pamięci, wysyłanie sterowników oprogramowania układowego, obsługa zdarzeń itd., jest taka sama w przypadku wszystkich (lub większości) systemów opartych na interfejsie UEFI. Sterowniki binarne oprogramowania układowego dla tych zadań można użyć ponownie na komputerach. Ponadto standardowe specyfikacje sprzętu i interfejsy umożliwiają typowym sterownikom oprogramowania układowego inicjowanie dysków twardych, kontrolerów USB i innych urządzeń peryferyjnych. Sterowniki binarne oprogramowania układowego dla tego sprzętu można również użyć ponownie na komputerach. Podsumowując, komputery można uruchomić z minimalnym zestawem typowych sterowników oprogramowania układowego.

Zmniejszenie całkowitego zestawu sterowników oprogramowania układowego załadowanych podczas rozruchu może prowadzić do innych korzyści:

• Ulepszony czas rozruchu

• Zmniejszenie koordynacji dostawców aktualizacji

• Zmniejszona ekspozycja na usterkę

• Zmniejszona powierzchnia ataku

Weryfikacja ścieżki rozruchowej FASR i zgodność z wymaganiami zabezpieczonego rdzenia

Aby system FASR spełniał wymagania dotyczące ochrony oprogramowania układowego komputerów zabezpieczonych rdzeniami, musi zostać uruchomiony na certyfikowanej ścieżce rozruchowej. Oprogramowanie układowe FASR ułatwia to, dostarczając systemowi operacyjnemu manifest z podpisem firmy Microsoft nazywany manifestem FASR (mierzonym w module TPM), który zawiera oczekiwane wartości PCR dla sekwencji rozruchu modułu na certyfikowanej ścieżce. Można to porównać z rzeczywistą sekwencją rozruchu, która wystąpiła na ścieżce certyfikowanej. Jeśli te pomiary są zgodne, system uznaje się, że spełnia wymogi ochrony firmware'u programu Secured-core PC. Każde odchylenie od oczekiwanej certyfikowanej sekwencji ścieżki rozruchowej skutkuje niespodziewanymi pomiarami, które trafiają do rejestrów konfiguracji platformy (PCR) modułu TPM, wykrywane przez system operacyjny.

Ponadto system Windows ujawnia tylko tajne informacje chronione przez hypervisor po pomyślnej weryfikacji podpisanego manifestu FASR w odniesieniu do pomiarów zarejestrowanych podczas aktualnego rozruchu. W przypadku certyfikowanej ścieżki rozruchowej lub aktualizacji kapsuły, jeśli manifest FASR nie jest obecny, weryfikacja podpisu kończy się niepowodzeniem lub występuje niezgodność PCR, a tajne dane VSM nie zostaną niezapieczętowane ani zmigrowane.

Jak oprogramowanie układowe FASR odpowiada na ochronę pamięci i program SMM

Teraz, gdy zdefiniowano pojedynczy plik binarny podpisany przez firmę Microsoft z minimalnym zestawem funkcji, może zawierać podstawowe, ale brakujące zabezpieczenia oprogramowania układowego, które firma Microsoft współpracuje z partnerami w celu wprowadzenia na rynek. Certyfikowana ścieżka rozruchowa musi spełniać co najmniej następujące wymagania:

1. Kod nie odczytuje/zapisu w wartości NULL/stronie 0

2. Sekcje kodu obrazu i danych są oddzielone

3. Sekcje obrazów są ustawione według granicy strony (4 KB)

4. Dane są przydzielane wyłącznie do typów pamięci danych, a kod do typów pamięci kodu.

5. Obrazy kodu nie są ładowane z kodu dystrybuowanego jako binaria UEFI (tylko wyznaczonych dispatcherów)

6. Kod pozostaje w granicach przydzielonych buforów pamięci z użyciem stron strażniczych wokół alokacji stron.

7. Przepełnienie stosu można wykryć

8. Kod nie jest wykonywany ze stosu

9. Właściwość /NXCOMPAT DLL jest ustawiona w celu włączenia ochrony NX

ROM-y opcji stron trzecich, aplikacje UEFI i sterowniki UEFI często nie zostały zbudowane ani zweryfikowane w odniesieniu do tego zestawu wymagań. W związku z tym nie będą one wykonywane na certyfikowanej ścieżce rozruchowej. Niestandardowa ścieżka rozruchowa może opcjonalnie zdecydować się na obniżenie wymaganego poziomu ochrony, ale ta ścieżka nie jest uznawana przez system operacyjny za zgodną ze standardami komputerów z bezpiecznym jądrem.

Tryb zarządzania systemem (SMM)

SMM to specjalny tryb operacyjny procesora w architekturze x86. Stanowi on unikatowe wyzwanie dla zabezpieczeń systemu, ponieważ kod wykonywany w środowisku SMM jest nieprzezroczystym dla systemu operacyjnego i zazwyczaj jest wykonywany na najwyższym poziomie uprawnień (czasami określany jako "Pierścień -2") dowolnego oprogramowania na procesorze hosta. Przy wchodzeniu, program SMM konfiguruje swoje środowisko, ustawiając tabelę stron, tabelę wysyłania przerwań (IDT) i inne struktury systemowe. Program SMM reprezentuje znaczną powierzchnię ataków, która może być używana przez złośliwy kod w celu naruszenia lub obejścia ochrony systemu operacyjnego włączonej za pomocą zabezpieczeń opartych na wirtualizacji (VBS). Aby pomóc w ograniczeniu zagrożenia stwarzanego przez program SMM, funkcjonalność programu SMM może być koncepcyjnie podzielona na podstawową infrastrukturę programu SMM i sterowniki SMM w następujący sposób:

• Podstawowe funkcje programu SMM: kod wspólny dla wszystkich implementacji programu SMM wykonujących obowiązki dotyczące architektury i infrastruktury

• Sterowniki programu SMM: kod napisany w celu wykonania zadania specyficznego dla platformy w programie SMM

Niektóre kluczowe momenty w cyklu życia programu SMM są następujące:

1. Po ustanowieniu podstawy (lub rdzenia) programu SMM — początkowe ładowanie programu SMM (IPL)

2. Po załadowaniu sterowników SMM — nazywane rozpoczęciem działania sterowników SMM

3. Gdy następuje wejście do trybu SMM – poprzez przerwanie zarządzania systemem (SMI)

Ładowanie początkowego programu SMM (IPL)

Procesor ma specjalne funkcje, które przyznają kodowi programu SMM wysokie uprawnienia i pomagają je chronić. Na przykład zdefiniowano mechanizm umożliwiający wejście do trybu SMM za pośrednictwem zdarzeń oprogramowania lub sprzętu, instrukcja procesora jest używana do powrotu z trybu SMM, a kilka rejestrów jest zdefiniowanych w celu kontrolowania dostępu i konfiguracji blokady trybu SMM. Wiele z tych rejestrów kontrolnych jest skonfigurowanych przez kod IPL programu SMM w celu ograniczenia dostępu do obszaru pamięci, w którym są przechowywane kod i dane programu SMM (nazywane pamięcią RAM zarządzania systemem lub SMRAM).

Ponieważ obszar SMRAM znajduje się w pamięci głównej (DRAM), nie można go ustanowić, dopóki pamięć DRAM nie zostanie włączona podczas rozruchu. Procedury włączania pamięci DRAM różnią się w zależności od dostawcy krzemu, ale kilka megabajtów kodu można uruchomić bezpośrednio z pamięci podręcznej CPU LLC (w tym kodu, który inicjuje pamięć DRAM) przed udostępnieniem pamięci głównej.

Oprogramowanie układowe FASR przenosi punkt IPL SMM wcześniej w procesie rozruchu niż w większości innych systemów. Zmniejsza to możliwość, że osoba atakująca musi podważyć ten proces i przejąć kontrolę nad systemem przed skonfigurowaniem programu SMM. Aby lepiej zrozumieć to i inne ulepszenia wprowadzone w programie SMM w oprogramowaniu układowym FASR, musimy dowiedzieć się więcej o procesie rozruchu oprogramowania układowego.

Inicjalizacje platformy (PI) rozruchu w oprogramowaniu układowym UEFI

Nowoczesne oprogramowanie układowe komputera jest zbudowane wokół wielu specyfikacji. Specyfikacja UEFI definiuje interfejs między zgodnym z interfejsem UEFI systemem operacyjnym, takimi jak Windows i oprogramowanie układowe na urządzeniu. Inna specyfikacja o nazwie Specyfikacja inicjowania platformy (PI) definiuje sposób tworzenia sterowników oprogramowania układowego i szczegóły procesu rozruchu. Na wysokim poziomie specyfikacja UEFI może być traktowana jako jedna ze standardów, która umożliwia współpracę pojedynczego obrazu systemu Windows z wieloma różnymi urządzeniami, a specyfikacja PI może być traktowana jako jedna ze standardów, która umożliwia współdziałanie wielu obrazów oprogramowania układowego od różnych dostawców sprzętu. Obie specyfikacje są obsługiwane przez forum UEFI.

Specyfikacja PI definiuje fazy rozruchu i które sterowniki są przypisane do faz rozruchu. Podczas rozruchu oprogramowania układowego każda faza przekazuje kontrolę do następnej i, w większości przypadków, sterowniki z tej fazy nie są już używane, a tylko ważne dane są przekazywane do następnej fazy, co pozwala jej kontynuować proces rozruchu. Fazy rozruchu można podsumować w następujący sposób:

1. SEC — uzyskiwanie kontroli na wektorze resetu procesora CPU i przejście z kodu asemblera do kodu języka C w celu załadowania PEI.

2. PEI — zainicjowanie stanu systemu w celu załadowania DXE i inicjalizacji pamięci DRAM

3. DXE — wykonywanie pozostałej inicjalizacji systemu, która obejmuje zapewnienie wsparcia potrzebnego BDS do załadowania systemu operacyjnego.

4. BDS — odnajdź opcję uruchomienia dla bieżącego uruchomienia (na przykład program ładujący systemu operacyjnego) i spróbuj ją uruchomić

5. System operacyjny — jądro systemu operacyjnego

Ochrona początkowego ładowania programu SMM (IPL)

Tradycyjne oprogramowanie układowe zgodne ze specyfikacją UEFI PI ładuje SMM IPL w fazie rozruchu DXE. Oprogramowanie układowe FASR ładuje protokół IPL SMM w fazie rozruchu PEI. Zaufana baza obliczeniowa (TCB) dla systemu to całkowity zestaw mechanizmów ochrony, które go chronią, w tym sprzęt, oprogramowanie układowe i oprogramowanie. Przenosząc protokół IPL SMM z DXE do PEI, cała faza DXE (która jest większym i bogatszym środowiskiem niż PEI) jest usuwana z TCB. Na poniższym diagramie przedstawiono SMM IPL przeniesiony na wcześniejszy etap w procesie rozruchu interfejsu UEFI.

Kod PEI i DXE są wykonywane na pierścieniu 0 i nie są utrwalane (z kilkoma wyjątkami) w systemie operacyjnym. Kod SMM wykonywany jest z wyższymi uprawnieniami niż pierścień 0 (i hipernadzorca) i działa nadal w systemie operacyjnym, więc zapobieganie wpływowi luki w zabezpieczeniach DXE na ustanowienie SMM zmniejsza ogólną powierzchnię ataków systemu. Ponadto, ponieważ program SMM jest uruchamiany wcześniej w procesie rozruchu, bity blokady ustawione w celu ochrony programu SMM można włączyć wcześniej podczas rozruchu, co dodatkowo minimalizuje okno osoby atakującej w celu naruszenia zabezpieczeń programu SMM.

Ochrona procesu wysyłania sterownika SMM

W specyfikacji PI określone są dwa tryby SMM: Tradycyjny MM i Autonomiczny MM. Tradycyjny MM jest odpowiednikiem modelu oprogramowania SMM, używanego historycznie w oprogramowaniu układowym zgodnym ze specyfikacji PI, który stanowi większość oprogramowania układowego UEFI w branży. Autonomiczny MM to stosunkowo nowy tryb, który zmienia model historyczny w celu poprawy bezpieczeństwa środowiska SMM oraz zapobiegania typowym błędom popełnianym w Tradycyjnym MM, które na przestrzeni lat doprowadziły do licznych wyzwań związanych z przenośnością i bezpieczeństwem.

Oprogramowanie układowe FASR działa wyłącznie w trybie autonomicznym MM. Dzięki temu oprogramowanie układowe FASR może postępować zgodnie z zdyscyplinowanym podejściem do wykonywania kodu w trybie SMM. Obecnie wiele luk w zabezpieczeniach opartych na programie SMM wynika z nieprawidłowych rozwiązań dozwolonych w kodzie programu SMM w tradycyjnym programie MM, które można po prostu usunąć w autonomicznym programie MM. Na wysokim poziomie dzieje się tak, ponieważ — w modelu tradycyjny MM — sterownik SMM jest uruchamiany dwa razy, raz przez dyspozytora DXE w pierścieniu 0, a ponownie przez dyspozytora SMM. Zapewnia to duże możliwości wykonania kodu sterownika w środowisku DXE w celu buforowania wskaźników do zasobów spoza pamięci SMRAM, do których nie powinny uzyskiwać dostępu po zakończeniu punktu wejścia. Ataki, które polegają na kodzie SMM w celu wywołania kodu poza trybem SMM, są często nazywane "atakami typu SMM callout".

Ochrona dostępu do SMM

Dane są przekazywane do programu obsługi SMI za pośrednictwem struktury nazywanej "buforem komunikacji". Obsługiwacz SMI jest odpowiedzialny za weryfikowanie, czy dane spełniają określone wymagania w początkowym punkcie. Tabela łagodzenia zagrożeń bezpieczeństwa Windows SMM (WSMT) jest jednym z mechanizmów stosowanych w celu zmniejszenia zagrożeń, jakie niekontrolowane programy obsługi SMI stanowią dla zabezpieczeń opartych na wirtualizacji w systemie operacyjnym. Firma Microsoft przyczyniła się do kodu projektu TianoCore w celu poprawy weryfikacji buforu komunikacji. Oprócz zastosowania tych dwóch technik kod FASR implementuje również ścisłe zabezpieczenia dostępu do pamięci, co umożliwia kodowi programu SMM dostęp tylko do jawnie dozwolonych zakresów pamięci.

Nadzorca trybu zarządzania (nadzorca MM)

Podstawowy kod programu SMM jest wspólny i udostępniany z minimalnymi zmianami między systemami. Obszar ataków narzucony przez program SMM można znacznie zmniejszyć, wprowadzając separację uprawnień do środowiska programu SMM. Z tego powodu oprogramowanie układowe FASR zawiera nadzorcę SMM, który działa w samodzielnym trybie MM. Skutkuje to dobrze zdefiniowanym środowiskiem SMM z minimalnym TCB, w którym poziomy uprawnień są egzekwowane od momentu utworzenia. Nadzorca MM nakłada ograniczenia dotyczące dostępu do portów we/wy, dostępu do rejestru specyficznego dla modelu (MSR), dostępu MMIO, zapisywania stanu procesora CPU i dozwolonych instrukcji w środowisku programu SMM. Polityka nadzorcy SMM służy do konfigurowania szczegółów odnośnie ograniczania zasobów sprzętowych, a te szczegóły mogą ulec zmianie w zależności od generacji układu scalonego.

Zasady przeszły ostatnio na podejście domyślnego odrzucenia, znacznie ograniczające zasoby sprzętowe dostępne dla kodu spoza nadzorcy SMM. Ten nadzorca działa bez zależności sprzętowej od żadnych funkcji sprzętowych, które nie są często spotykane na nowoczesnych komputerach.

Nadzorca MM używany w FASR jest typu open source i dostępny w repozytorium Nadzorcy MM projektu Mu.

Zgodność systemu FASR z wymaganiami dotyczącymi komputera z zabezpieczonym rdzeniem

W poniższej tabeli przedstawiono główne filary zabezpieczeń lub cele komputerów z zabezpieczonym rdzeniem oraz sposób, w jaki uruchamianie systemów FASR w certyfikowanej ścieżce może spełniać wymagania komputerów z zabezpieczonym rdzeniem.

Jeśli system nie ma zaawansowanych funkcji zabezpieczeń do obsługi D-RTM, wymagania dotyczące ochrony oprogramowania układowego można spełnić przy użyciu kombinacji S-RTM i autonomicznej MM z nadzorcą MM, które są oferowane przez oprogramowanie układowe FASR.

Podsumowanie

Są to niektóre inwestycje, które firma Microsoft poczyniła w celu rozwiązania rosnącej liczby ataków oprogramowania układowego, które są obecnie powszechne w całej branży. Korzystając z kodu open source dla tych zmian, możemy umożliwić naszym partnerom korzystanie z niektórych z tych korzyści zabezpieczeń, co z kolei przyniesie korzyści szerszemu ekosystemowi i branży.

Głównym celem inicjatywy bezpiecznego komputera jest zapewnienie klientom dostępu do niektórych z najbardziej zaawansowanych funkcji zabezpieczeń dostępnych dla komputerów z systemem Windows. W przypadku niektórych z tych zmian oprogramowania układowego jesteśmy o krok bliżej realizacji tego celu i zaktualizowaliśmy wymagania dotyczące ochrony komputerów rdzenia zabezpieczonego, aby to uwzględnić. Dowiedz się więcej o komputerach z zabezpieczeniem podstawowym tutaj.