W ramach frameworku InsydeH2O, stosowanego przez wielu producentów do tworzenia firmware UEFI dla swojego sprzętu (najczęściej spotykana implementacja UEFI BIOS), zidentyfikowano 23 podatności, które pozwalają na wykonanie kodu na poziomie SMM (System Management Mode), bardziej priorytetowym (Ring -2) niż hiperwizor i zerowy poziom ochrony, mającym nieograniczony dostęp do całej pamięci. Problem dotyczy firmware UEFI używanego przez takich producentów jak Fujitsu, Siemens, Dell, HP, HPE, Lenovo, Microsoft, Intel i Bull Atos.
Do wykorzystania podatności wymagany jest lokalny dostęp z uprawnieniami administratora, co sprawia, że problemy te są poszukiwane jako podatności drugiego stopnia, stosowane po wykorzystaniu innych podatności w systemie lub przy użyciu metod inżynierii społecznej. Dostęp na poziomie SMM pozwala na wykonanie kodu na poziomie, niewidocznym dla systemu operacyjnego, co może być wykorzystane do modyfikacji firmware'u i umieszczania w SPI Flash ukrytego złośliwego kodu lub rootkitów, niewykrywalnych przez system operacyjny, a także do wyłączenia weryfikacji podczas rozruchu (UEFI Secure Boot, Intel BootGuard) i ataków na hiperwizory w celu obejścia mechanizmów weryfikacji integralności wirtualnych środowisk.
Wykorzystanie podatności można przeprowadzić z poziomu systemu operacyjnego za pomocą nieweryfikowanych obsług SMI (System Management Interrupt), a także na etapie przed uruchomieniem systemu operacyjnego podczas początkowych faz rozruchu lub z wybudzenia. Wszystkie podatności są spowodowane problemami związanymi z pamięcią i dzielą się na trzy kategorie:
- SMM Callout — wykonanie własnego kodu z prawami SMM poprzez przekierowanie wykonania procedur przerwań SWSMI na kod poza SMRAM;
- Uszkodzenia pamięci, które pozwalają atakującemu zapisać swoje dane w SMRAM, specjalnej izolowanej strefie pamięci, w której wykonywany jest kod z uprawnieniami SMM.
- Uszkodzenie pamięci w kodzie wykonywanym na poziomie DXE (Driver eXecution Environment).
Aby zademonstrować zasady organizacji ataku, opublikowano przykład exploit, który pozwala na uzyskanie dostępu do runtime DXE UEFI i wykonanie własnego kodu poprzez przeprowadzenie ataku z trzeciego lub zerowego kręgu ochrony. Exploit manipuluje przepełnieniem stosu (CVE-2021-42059) w sterowniku UEFI DXE. W trakcie ataku atakujący może umieścić swój kod w sterowniku DXE, który pozostaje aktywny po ponownym uruchomieniu systemu operacyjnego, lub wprowadzić zmiany w obszarze NVRAM w pamięci SPI Flash. Podczas wykonania kod atakującego może wprowadzać zmiany w uprzywilejowanych obszarach pamięci, modyfikować usługi EFI Runtime i wpływać na proces rozruchu.
Źródło: opennet.ru
