W frameworku InsydeH2O, wykorzystywanym przez wielu producentów do tworzenia oprogramowania UEFI dla ich sprzętu (najpopularniejsza implementacja UEFI BIOS), zidentyfikowano 23 podatności umożliwiające wykonanie kodu na poziomie SMM (System Management Mode), który posiada wyższy priorytet (Ring -2) niż tryb hypervisora i zerowy pierścień ochrony oraz nieograniczony dostęp do całej pamięci. Problem dotyczy oprogramowania sprzętowego UEFI używanego przez producentów takich jak Fujitsu, Siemens, Dell, HP, HPE, Lenovo, Microsoft, Intel i Bull Atos.
Wykorzystanie podatności wymaga lokalnego dostępu z uprawnieniami administratora, co sprawia, że problemy te są popularne jako luki drugiego rzędu, wykorzystywane po wykorzystaniu innych podatności w systemie lub zastosowaniu metod socjotechniki. Dostęp na poziomie SMM pozwala na wykonanie kodu na poziomie niekontrolowanym przez system operacyjny, co może zostać wykorzystane do modyfikacji oprogramowania sprzętowego i pozostawienia ukrytego w SPI Flash złośliwego kodu lub rootkitów, które nie są wykrywane przez system operacyjny, a także w celu wyłączenia weryfikacji na etapie rozruchu (UEFI Secure Boot, Intel BootGuard) oraz ataków na hypervisory w celu ominięcia mechanizmów sprawdzających integralność środowisk wirtualnych.
Eksploatacja podatności może odbywać się z poziomu systemu operacyjnego przy użyciu niezweryfikowanych procedur obsługi SMI (ang. System Management Interrupt), jak również na etapie przed wykonaniem systemu operacyjnego podczas początkowych etapów uruchamiania systemu lub powrotu z trybu uśpienia. Wszystkie luki są spowodowane problemami z pamięcią i dzielą się na trzy kategorie:
- SMM Callout - wykonanie Twojego kodu z uprawnieniami SMM poprzez przekierowanie wykonywania procedur obsługi przerwań SWSMI do kodu spoza SMRAM;
- Uszkodzenie pamięci umożliwiające atakującemu zapisanie danych w SMRAM, specjalnym izolowanym obszarze pamięci, w którym wykonywany jest kod z uprawnieniami SMM.
- Uszkodzenie pamięci w kodzie działającym na poziomie DXE (Driver eXecution Environment).
Aby zademonstrować zasady organizacji ataku, opublikowano przykład exploita, który pozwala poprzez atak z trzeciego lub zerowego pierścienia ochrony uzyskać dostęp do DXE Runtime UEFI i wykonać swój kod. Exploit manipuluje przepełnieniem stosu (CVE-2021-42059) w sterowniku UEFI DXE. Podczas ataku atakujący może umieścić swój kod w sterowniku DXE, który pozostaje aktywny po ponownym uruchomieniu systemu operacyjnego lub dokonać zmian w obszarze NVRAM pamięci SPI Flash. Podczas wykonywania kod atakującego może wprowadzić zmiany w uprzywilejowanych obszarach pamięci, zmodyfikować usługi EFI Runtime i wpłynąć na proces rozruchu.
Źródło: opennet.ru