Zidentyfikowano lukę (CVE-2-2023) w sterowniku, który zapewnia obsługę systemu plików NTFS w bootloaderze GRUB4692, umożliwiając wykonanie jego kodu na poziomie bootloadera podczas uzyskiwania dostępu do specjalnie zaprojektowanego obrazu systemu plików. Luka może zostać wykorzystana do ominięcia mechanizmu rozruchu zweryfikowanego przez UEFI Secure Boot.
Luka jest spowodowana błędem w kodzie parsowania atrybutu NTFS „$ATTRIBUTE_LIST” (grub-core/fs/ntfs.c), który może być użyty do zapisania kontrolowanych przez użytkownika informacji w obszarze pamięci poza przydzielonym buforem. Podczas przetwarzania specjalnie spreparowanego obrazu NTFS przepełnienie prowadzi do nadpisania części pamięci GRUB i, w pewnych warunkach, do uszkodzenia obszaru pamięci oprogramowania układowego UEFI, co potencjalnie umożliwia wykonanie niestandardowego kodu na poziomie bootloadera lub oprogramowania układowego.
Ponadto odkryto kolejną lukę (CVE-2-2023) w sterowniku NTFS z GRUB4693, która umożliwia odczytanie zawartości dowolnego obszaru pamięci podczas parsowania atrybutu „$DATA” w specjalnie zaprojektowanym obrazie NTFS. Luka umożliwia między innymi wyodrębnienie poufnych danych buforowanych w pamięci lub ustalenie wartości zmiennych EFI.
Problemy zostały na razie tylko załatane. Status poprawek luk w zabezpieczeniach w dystrybucjach można sprawdzić na tych stronach: Debian, Ubuntu, SUSE, RHEL, Fedora. Naprawa problemów z GRUB2 wymaga czegoś więcej niż tylko aktualizacji pakietu; wymaga również wygenerowania nowych wewnętrznych podpisów cyfrowych oraz aktualizacji instalatorów, bootloaderów, pakietów jądra, oprogramowania sprzętowego fwupd i warstwy shim.
W większości LinuxDystrybucje z weryfikowanym rozruchem w trybie UEFI Secure Boot wykorzystują niewielką warstwę shim, podpisaną cyfrowo przez firmę Microsoft. Warstwa ta weryfikuje GRUB2 za pomocą własnego certyfikatu, eliminując konieczność powiadamiania firmy Microsoft przez twórców dystrybucji o każdej aktualizacji jądra i GRUB-a. Luki w zabezpieczeniach GRUB2 umożliwiają wykonanie dowolnego kodu po pomyślnej weryfikacji shim, ale przed uruchomieniem systemu operacyjnego. Pozwala to atakującym na włamanie się do łańcucha zaufania po włączeniu funkcji Secure Boot i uzyskanie pełnej kontroli nad procesem rozruchu, na przykład w celu uruchomienia innego systemu operacyjnego, modyfikacji komponentów systemu operacyjnego lub obejścia ochrony Lockdown.
Aby zablokować lukę bez unieważniania podpisu cyfrowego, dystrybucje mogą wykorzystać mechanizm SBAT (UEFI Secure Boot Advanced Targeting), którego obsługę zaimplementowano w GRUB2, shim i fwupd w większości popularnych dystrybucji. LinuxSBAT został opracowany we współpracy z firmą Microsoft i polega na dodawaniu dodatkowych metadanych do plików wykonywalnych komponentów UEFI, w tym informacji o producencie, produkcie, komponencie i wersji. Metadane te są podpisane cyfrowo i mogą być oddzielnie uwzględniane na listach dozwolonych lub zabronionych komponentów dla funkcji UEFI Secure Boot.
SBAT umożliwia blokowanie użycia podpisów cyfrowych dla poszczególnych numerów wersji komponentów bez konieczności odwoływania kluczy dla Secure Boot. Blokowanie luk za pośrednictwem SBAT nie wymaga użycia listy odwołanych certyfikatów UEFI (dbx), ale odbywa się na poziomie zastąpienia wewnętrznego klucza do generowania podpisów i aktualizacji GRUB2, shim i innych artefaktów rozruchowych dostarczanych przez dystrybucje. Przed wprowadzeniem SBAT aktualizacja listy odwołanych certyfikatów (dbx, UEFI Revocation List) była obowiązkowym warunkiem całkowitego zablokowania luki, ponieważ atakujący, niezależnie od używanego systemu operacyjnego, mógł użyć klucza rozruchowego do złamania zabezpieczeń UEFI Secure Boot
Źródło: opennet.ru
