Opublikowano informacje o 21 podatnościach w bootloaderze GRUB2, z czego większość prowadzi do przepełnienia bufora i może być wykorzystywana do obejścia mechanizmu weryfikowanej ładowności UEFI Secure Boot. Problemy zostały dotychczas usunięte jedynie w formie łatki. Status usunięcia podatności w dystrybucjach można ocenić na tych stronach: Debian, Ubuntu, SUSE, RHEL, Fedora. Aby rozwiązać problemy z GRUB2, wystarczy nie tylko zaktualizować pakiet, ale także utworzyć nowe wewnętrzne cyfrowe podpisy oraz zaktualizować instalatory, bootloadery, pakiety jądra, fwupd-firmware i warstwę shim.
Zidentyfikowane luki:
- CVE-2024-45774: zapisywanie poza granicami bufora podczas analizy specjalnie przygotowanych obrazów JPEG.
- CVE-2024-45776, CVE-2024-45777: przepełnienia liczb całkowitych podczas odczytu specjalnie przygotowanych plików mo, prowadzące do zapisywania poza granicami bufora.
- CVE-2024-45778, CVE-2024-45779: przepełnienia liczb całkowitych podczas pracy z uszkodzonym systemem plików BFS, prowadzące do przepełnienia bufora.
- CVE-2024-45780: przepełnienie liczb całkowitych podczas przetwarzania specjalnie przygotowanych archiwów tar, prowadzące do zapisywania poza granicami bufora.
- CVE-2024-45781, CVE-2025-0677: przepełnienia bufora podczas pracy z uszkodzonym systemem plików UFS.
- CVE-2024-45782, CVE-2025-1125: przepełnienia bufora podczas montowania specjalnie przygotowanej partycji HFS.
- CVE-2025-0622: dostęp do pamięci po jej zwolnieniu podczas manipulacji modułami, co może prowadzić do wykonania kodu atakującego.
- CVE-2025-0624: przepełnienie bufora podczas sieciowego ładowania.
- CVE-2025-0678: przepełnienia bufora podczas pracy z uszkodzonym systemem plików Squash4.
- CVE-2025-0684: przepełnienia bufora podczas manipulacji z symlinkami w systemie plików Reiserfs.
- CVE-2025-0685: przepełnienia bufora podczas manipulacji z symlinkami w systemie plików JFS.
- CVE-2025-0685: przepełnienia bufora podczas manipulacji z symlinkami w systemie plików ROMFS.
- CVE-2025-0689: przepełnienia bufora podczas pracy ze specjalnie zmodyfikowaną partycją UDF.
- CVE-2025-0690: przepełnienia bufora podczas odbierania specjalnie przygotowanych danych z klawiatury.
- CVE-2025-1118: obejście trybu izolacji Lockdown i wyciąganie dowolnego zawartości pamięci poprzez wykonanie polecenia dump.
- CVE-2024-45775: brak sprawdzenia kodu błędu podczas alokacji pamięci przy analizie przekazanych argumentów może prowadzić do uszkodzenia danych IVT (Interrupt Vector Table).
- CVE-2024-45783: dostęp do pustego wskaźnika przy montowaniu niepoprawnej systemu plików HFS+.
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 pozwala zablokować użycie cyfrowego podpisu dla poszczególnych numerów wersji komponentów bez konieczności wycofywania kluczy dla Secure Boot. Blokowanie podatności przez SBAT nie wymaga korzystania z listy wycofanych certyfikatów UEFI (dbx), a odbywa się na poziomie zastąpienia wewnętrznego klucza do formowania podpisów i aktualizacji GRUB2, shim i innych dostarczanych przez dystrybucje artefaktów rozruchowych. Do wprowadzenia SBAT, aktualizacja listy wycofanych certyfikatów (dbx, UEFI Revocation List) była obowiązkowym warunkiem pełnego zablokowania podatności, ponieważ atakujący, niezależnie od używanego systemu operacyjnego, mógł do skompromitowania UEFI Secure Boot użyć nośnika rozruchowego ze starszą podatną wersją GRUB2, opatentowaną cyfrowym podpisem.
Źródło: opennet.ru
