Odsłonięto informacje o 8 lukach w bootloaderze GRUB2, które pozwalają na obejście mechanizmu UEFI Secure Boot i uruchomienie niezweryfikowanego kodu, na przykład na wprowadzenie złośliwego oprogramowania działającego na poziomie bootloadera lub jądra.
Przypomnijmy, że w większości dystrybucji Linuxa, dla zweryfikowanego uruchamiania w trybie UEFI Secure Boot używana jest mała warstwa shim, certyfikowana cyfrowym podpisem Microsoft. Ta warstwa weryfikuje GRUB2 swoim własnym certyfikatem, co pozwala twórcom dystrybucji nie certyfikować każdej aktualizacji jądra i GRUB w Microsoft. Luki w GRUB2 pozwalają na wykonanie własnego kodu na etapie po pomyślnej weryfikacji shim, ale przed załadowaniem systemu operacyjnego, wplatając się w łańcuch zaufania przy aktywnym trybie Secure Boot i uzyskując pełną kontrolę nad dalszym procesem uruchamiania, w tym za ładowaniem innego systemu operacyjnego, modyfikacją komponentów systemu operacyjnego i obchodzeniem ochrony Lockdown.
Podobnie jak w przypadku zeszłorocznej luki BootHole, aby zablokować problem, nie wystarczy zaktualizować bootloadera, ponieważ atakujący, niezależnie od używanego systemu operacyjnego, może dla skompromitowania UEFI Secure Boot użyć nośnika bootującego z starszą, podatną wersją GRUB2, certyfikowaną cyfrowym podpisem. Problem rozwiązuje się tylko poprzez zaktualizowanie listy unieważnionych certyfikatów (dbx, UEFI Revocation List), ale w tym przypadku utracona zostanie możliwość korzystania ze starych nośników instalacyjnych z Linuksem.
Na systemach z oprogramowaniem układowym, w którym zaktualizowano listę unieważnionych certyfikatów, w trybie UEFI Secure Boot będzie można załadować tylko zaktualizowane wersje dystrybucji Linuxa. Dystrybucje będą musiały zaktualizować instalatory, bootloadery, pakiety jądra, firmware fwupd i warstwę shim, generując dla nich nowe cyfrowe podpisy. Użytkownicy będą musieli zaktualizować obrazy instalacyjne i inne nośniki bootujące, a także załadować listę unieważnionych certyfikatów (dbx) do firmware UEFI. Dopóki dbx nie zostanie zaktualizowane w UEFI, system pozostaje podatny niezależnie od zainstalowanych aktualizacji w systemie operacyjnym. Status usunięcia luk można ocenić na tych stronach: Ubuntu, SUSE, RHEL, Debian.
Aby rozwiązać problemy związane z dystrybucją odwołanych certyfikatów, w przyszłości planowane jest wykorzystanie mechanizmu SBAT (UEFI Secure Boot Advanced Targeting), którego wsparcie zostało zrealizowane dla GRUB2, shim i fwupd. Od następnych aktualizacji będzie on używany zamiast funkcjonalności oferowanej przez pakiet dbxtool. SBAT został opracowany wspólnie z Microsoftem i zakłada dodanie do plików wykonywalnych komponentów UEFI nowych metadanych, które zawierają informacje o producencie, produkcie, komponencie i wersji. Wskazane metadane są podpisywane cyfrowo i mogą być dodatkowo uwzględniane na listach dozwolonych lub zabronionych komponentów dla UEFI Secure Boot. Dzięki temu SBAT umożliwi manipulowanie numerami wersji komponentów w przypadku ich odwołania bez konieczności regenerowania kluczy dla Secure Boot oraz bez tworzenia nowych podpisów dla jądra, shim, grub2 i fwupd.
Zidentyfikowane luki:
- CVE-2020-14372 — dzięki poleceniu acpi w GRUB2 uprzywilejowany użytkownik lokalny może załadować zmodyfikowane tabele ACPI, umieszczając SSDT (Secondary System Description Table) w katalogu /boot/efi i zmieniając ustawienia w grub.cfg. Mimo aktywnego trybu Secure Boot, proponowany SSDT zostanie wykonany przez jądro i może być użyty do wyłączenia ochrony LockDown, blokującej drogi obejścia UEFI Secure Boot. W konsekwencji atakujący może załadować swój moduł jądra lub uruchomić kod poprzez mechanizm kexec, bez sprawdzania podpisu cyfrowego.
- CVE-2020-25632 — dostęp do już zwolnionego obszaru pamięci (use-after-free) w implementacji polecenia rmmod, pojawiający się przy próbie odłączenia dowolnego modułu bez uwzględnienia jego zależności. Luka nie wyklucza stworzenia exploita, który może prowadzić do wykonania kodu z pominięciem weryfikacji Secure Boot.
- CVE-2020-25647 — zapis poza granicami bufora w funkcji grub_usb_device_initialize(), wywoływanej podczas inicjalizacji urządzeń USB. Problem może być wykorzystany poprzez podłączenie specjalnie przygotowanego urządzenia USB, które dostarcza parametry o rozmiarze, który nie odpowiada rozmiarowi bufora przeznaczonego dla struktur USB. Atakujący może osiągnąć wykonanie kodu, nieweryfikowanego w Secure Boot, poprzez manipulacje urządzeniami USB.
- CVE-2020-27749 — przepełnienie bufora w funkcji grub_parser_split_cmdline(), które może być wywołane przez podanie w linii poleceń GRUB2 zmiennych o rozmiarze większym niż 1 KB. Luka ta umożliwia wykonanie kodu z pominięciem Secure Boot.
- CVE-2020-27779 — polecenie cutmem pozwala atakującemu usunąć zakres adresów z pamięci w celu obejścia Secure Boot.
- CVE-2021-3418 — zmiany w shim_lock stworzyły dodatkowy wektor dla eksploatacji ubiegłorocznej luki CVE-2020-15705. Przy dodawaniu do dbx certyfikatu używanego do podpisywania GRUB2, GRUB2 pozwalał bezpośrednio załadować jądro bez weryfikacji podpisu.
- CVE-2021-20225 — możliwość zapisu danych poza buforem podczas uruchamiania poleceń z bardzo dużą liczbą opcji.
- CVE-2021-20233 — możliwość zapisu danych poza granicą bufora z powodu błędnego obliczenia rozmiaru bufora przy użyciu cudzysłowów. Przy obliczaniu rozmiaru przyjęto, że do odpowiedniego zabezpieczenia pojedynczego cudzysłowu potrzeba trzech znaków, podczas gdy w rzeczywistości potrzeba czterech.
Źródło: opennet.ru
