W sterowniku, który obsługuje system plików NTFS w bootloaderze GRUB2, zidentyfikowano lukę (CVE-2023-4692), która pozwala na uruchomienie swojego kodu na poziomie bootloadera przy próbie dostępu do specjalnie przygotowanego obrazu systemu plików. Luka może być wykorzystywana do obejścia mechanizmu weryfikowanego rozruchu UEFI Secure Boot.
Luka jest spowodowana błędem w kodzie analizy atrybutu NTFS „$ATTRIBUTE_LIST” (grub-core/fs/ntfs.c), który może być wykorzystany do zapisu kontrolowanych przez użytkownika informacji w obszarze pamięci poza przydzielonym buforem. Podczas przetwarzania specjalnie przygotowanego obrazu NTFS przepełnienie prowadzi do nadpisania części pamięci GRUB, a także, w określonych warunkach, do uszkodzenia obszaru pamięci firmware UEFI, co potencjalnie pozwala na uruchomienie swojego kodu na poziomie bootloadera lub firmware.
Ponadto w sterowniku NTFS z GRUB2 zidentyfikowano jeszcze jedną lukę (CVE-2023-4693), która pozwala na odczytanie zawartości dowolnego obszaru pamięci podczas analizy atrybutu „$DATA” w specjalnie przygotowanym obrazie NTFS. Między innymi luka pozwala na wyciągnięcie poufnych danych, które są buforowane w pamięci, lub określenie wartości zmiennych EFI.
Problemy zostały na razie rozwiązane tylko w postaci łaty. Status usunięcia luk w dystrybucjach można ocenić na tych stronach: Debian, Ubuntu, SUSE, RHEL, Fedora. Aby rozwiązać problemy w GRUB2, wystarczy nie tylko zaktualizować pakiet, ale także utworzyć nowe wewnętrzne podpisy cyfrowe oraz zaktualizować instalatory, bootloadery, pakiety jądra, firmware fwupd i warstwę shim.
W większości dystrybucji Linuxa do weryfikacji rozruchu w trybie UEFI Secure Boot używana jest mała warstwa shim, opatentowana cyfrowym podpisem Microsoft. Ta warstwa weryfikuje GRUB2 własnym certyfikatem, co pozwala deweloperom dystrybucji nie opatrywać każdym aktualizacją jądra i GRUB w Microsoft. W vulnerabilności w GRUB2 pozwalają na wykonanie własnego kodu na etapie po udanej weryfikacji shim, ale przed załadowaniem systemu operacyjnego, wbijając się w łańcuch zaufania przy aktywnym trybie Secure Boot i uzyskując pełną kontrolę nad dalszym procesem ładowania, na przykład, aby załadować inny system operacyjny, zmodyfikować komponenty systemu operacyjnego i obejść zabezpieczenia Lockdown.
Aby zablokować podatność bez wycofywania cyfrowego podpisu, dystrybucje mogą wykorzystać mechanizm SBAT (UEFI Secure Boot Advanced Targeting), którego wsparcie zostało wdrożone dla GRUB2, shim i fwupd w większości popularnych dystrybucji Linux. SBAT został zaprojektowany wspólnie z Microsoftem i zakłada dodanie do wykonywalnych plików komponentów UEFI dodatkowych metadanych, które zawierają informacje o producencie, produkcie, komponencie i wersji. Podane metadane są podpisywane cyfrowym podpisem i mogą być osobno dołączane do list dozwolonych lub zabronionych komponentów dla UEFI Secure Boot.
SBAT umożliwia blokowanie użycia cyfrowego podpisu dla poszczególnych wersji komponentów bez potrzeby wycofywania kluczy dla Secure Boot. Blokowanie luk w zabezpieczeniach poprzez SBAT nie wymaga korzystania z listy wycofanych certyfikatów UEFI (dbx) i odbywa się na poziomie wymiany wewnętrznego klucza do generowania podpisów oraz aktualizacji GRUB2, shim i innych dostarczanych przez dystrybucje artekfaktów rozruchowych. Przed wprowadzeniem SBAT aktualizacja listy wycofanych certyfikatów (dbx, UEFI Revocation List) była obligatoryjnym warunkiem pełnego zablokowania luk, ponieważ atakujący, niezależnie od używanego systemu operacyjnego, mógł wykorzystać rozruchowy do kompromitacji UEFI Secure Boot.
Źródło: opennet.ru
