Ujawniono informację o 8 lukach w bootloaderze GRUB2, które pozwalają ominąć mechanizm UEFI Secure Boot i uruchomić niezweryfikowany kod, np. zaimplementować złośliwe oprogramowanie działające na poziomie bootloadera lub jądra.
Przypomnijmy, że w większości dystrybucji Linuksa do zweryfikowania rozruchu w trybie UEFI Secure Boot wykorzystywana jest niewielka warstwa podkładkowa, podpisana cyfrowo przez Microsoft. Ta warstwa weryfikuje GRUB2 za pomocą własnego certyfikatu, co pozwala twórcom dystrybucji nie mieć certyfikatu każdego jądra i aktualizacji GRUB-a przez Microsoft. Luki w GRUB2 pozwalają na wykonanie kodu na etapie po udanej weryfikacji podkładki, ale przed załadowaniem systemu operacyjnego, wklinowanie się w łańcuch zaufania, gdy tryb Bezpiecznego rozruchu jest aktywny i uzyskanie pełnej kontroli nad dalszym procesem rozruchu, w tym ładowanie innego systemu operacyjnego, modyfikowanie komponentów systemu operacyjnego i omijanie ochrony Lockdown.
Podobnie jak w przypadku zeszłorocznej luki BootHole, aktualizacja programu ładującego nie wystarczy, aby zablokować problem, ponieważ osoba atakująca, niezależnie od używanego systemu operacyjnego, może użyć nośnika startowego ze starą, podpisaną cyfrowo, podatną na ataki wersję GRUB2, aby złamać bezpieczeństwo UEFI Secure Boot. Problem można rozwiązać jedynie poprzez aktualizację listy unieważnionych certyfikatów (dbx, UEFI Revocation List), ale w tym przypadku stracona zostanie możliwość korzystania ze starych nośników instalacyjnych z Linuksem.
W systemach z oprogramowaniem sprzętowym, które ma zaktualizowaną listę odwołanych certyfikatów, w trybie UEFI Secure Boot można ładować tylko zaktualizowane kompilacje dystrybucji Linuksa. Dystrybucje będą musiały zaktualizować instalatory, programy ładujące, pakiety jądra, oprogramowanie sprzętowe fwupd i warstwę podkładki, generując dla nich nowe podpisy cyfrowe. Użytkownicy będą musieli zaktualizować obrazy instalacyjne i inne nośniki startowe, a także załadować listę odwołań certyfikatów (dbx) do oprogramowania sprzętowego UEFI. Przed aktualizacją dbx do UEFI system pozostaje podatny na ataki niezależnie od instalacji aktualizacji w systemie operacyjnym. Stan luk można ocenić na stronach: Ubuntu, SUSE, RHEL, Debian.
Aby rozwiązać problemy pojawiające się przy dystrybucji unieważnionych certyfikatów, w przyszłości planowane jest wykorzystanie mechanizmu SBAT (UEFI Secure Boot Advanced Targeting), którego obsługa została zaimplementowana dla GRUB2, shim i fwupd i począwszy od kolejnych aktualizacji będzie używane zamiast funkcjonalności zapewnianej przez pakiet dbxtool. SBAT został opracowany wspólnie z firmą Microsoft i polega na dodaniu do plików wykonywalnych komponentów UEFI nowych metadanych, które obejmują informacje o producencie, produkcie, komponencie i wersji. Podane metadane są certyfikowane podpisem cyfrowym i dodatkowo mogą zostać uwzględnione na listach dozwolonych lub zabronionych komponentów dla UEFI Secure Boot. W ten sposób SBAT umożliwi manipulowanie numerami wersji komponentów podczas unieważniania bez konieczności ponownego generowania kluczy dla Bezpiecznego rozruchu i bez generowania nowych sygnatur dla jądra, podkładki, grub2 i fwupd.
Zidentyfikowane podatności:
- CVE-2020-14372 – Za pomocą polecenia acpi w GRUB2 uprzywilejowany użytkownik systemu lokalnego może załadować zmodyfikowane tabele ACPI, umieszczając SSDT (tabelę opisu systemu dodatkowego) w katalogu /boot/efi i zmieniając ustawienia w grub.cfg. Chociaż tryb bezpiecznego rozruchu jest aktywny, proponowany SSDT zostanie wykonany przez jądro i może zostać użyty do wyłączenia ochrony LockDown, która blokuje ścieżki obejścia UEFI Secure Boot. W rezultacie osoba atakująca może załadować swój moduł jądra lub uruchomić kod poprzez mechanizm kexec, bez sprawdzania podpisu cyfrowego.
- CVE-2020-25632 to dostęp do pamięci po zwolnieniu w implementacji polecenia rmmod, który występuje, gdy podejmowana jest próba wyładowania dowolnego modułu bez uwzględnienia powiązanych z nim zależności. Podatność nie wyklucza stworzenia exploita, który może doprowadzić do wykonania kodu z pominięciem weryfikacji Secure Boot.
- CVE-2020-25647 Zapis poza granicami w funkcji grub_usb_device_initialize() wywoływanej podczas inicjowania urządzeń USB. Problem można wykorzystać podłączając specjalnie przygotowane urządzenie USB, które generuje parametry, których wielkość nie odpowiada wielkości bufora przeznaczonego dla struktur USB. Osoba atakująca może spowodować wykonanie kodu, który nie jest zweryfikowany w trybie bezpiecznego rozruchu, poprzez manipulację urządzeniami USB.
- CVE-2020-27749 to przepełnienie bufora w funkcji grub_parser_split_cmdline(), które może być spowodowane podaniem zmiennych większych niż 2 KB w wierszu poleceń GRUB1. Luka umożliwia wykonanie kodu z ominięciem bezpiecznego rozruchu.
- CVE-2020-27779 – Polecenie cutmem umożliwia atakującemu usunięcie zakresu adresów z pamięci w celu ominięcia bezpiecznego rozruchu.
- CVE-2021-3418 — Zmiany w shim_lock stworzyły dodatkowy wektor umożliwiający wykorzystanie zeszłorocznej luki CVE-2020-15705. Instalując certyfikat używany do podpisywania GRUB2 w dbx, GRUB2 umożliwił bezpośrednie załadowanie dowolnego jądra bez sprawdzania podpisu.
- CVE-2021-20225 - Możliwość zapisu danych spoza zakresu podczas uruchamiania poleceń z bardzo dużą liczbą opcji.
- CVE-2021-20233 – Możliwość zapisu danych poza zakresem z powodu nieprawidłowego obliczenia rozmiaru bufora podczas korzystania z cudzysłowów. Przy obliczaniu rozmiaru założono, że do ucieczki z pojedynczego cudzysłowu potrzebne są trzy znaki, podczas gdy w rzeczywistości potrzebne były cztery.
Źródło: opennet.ru