Ujawniono informację o dwóch lukach w bootloaderze GRUB2, które mogą doprowadzić do wykonania kodu w przypadku użycia specjalnie zaprojektowanych czcionek i przetwarzania określonych sekwencji Unicode. Luki można wykorzystać do ominięcia mechanizmu rozruchu zweryfikowanego UEFI Secure Boot.
Zidentyfikowane podatności:
- CVE-2022-2601 - Przepełnienie bufora w funkcji grub_font_construct_glyph() podczas przetwarzania specjalnie zaprojektowanych czcionek w formacie pf2, które występuje na skutek nieprawidłowego obliczenia parametru max_glyph_size i przydzielenia obszaru pamięci wyraźnie mniejszego niż jest to konieczne do dostosować się do glifów.
- CVE-2022-3775 Podczas renderowania niektórych sekwencji Unicode przy użyciu specjalnie stylizowanej czcionki występuje zapis poza dopuszczalnym zakresem. Problem leży w kodzie przetwarzającym czcionkę i jest spowodowany brakiem odpowiednich kontroli zapewniających, że szerokość i wysokość glifu odpowiadają rozmiarowi dostępnej mapy bitowej. Osoba atakująca może spreparować dane wejściowe w taki sposób, aby spowodować zapisanie końca danych na zewnątrz przydzielonego bufora. Należy zauważyć, że pomimo złożoności wykorzystania luki, nie wyklucza się sprowadzenia problemu do wykonania kodu.
Poprawka została opublikowana jako łatka. Stan eliminacji podatności w dystrybucjach można ocenić na stronach: Ubuntu, SUSE, RHEL, Fedora, Debian. Aby naprawić problemy w GRUB2, nie wystarczy po prostu zaktualizować pakiet; musisz także wygenerować nowe wewnętrzne podpisy cyfrowe i zaktualizować instalatory, programy ładujące, pakiety jądra, oprogramowanie sprzętowe fwupd i warstwę podkładki.
Większość dystrybucji Linuksa korzysta z małej warstwy podkładki podpisanej cyfrowo przez firmę Microsoft w celu zweryfikowania rozruchu w trybie bezpiecznego rozruchu UEFI. 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.
Aby zablokować lukę bez unieważniania podpisu cyfrowego, dystrybucje mogą korzystać z mechanizmu SBAT (UEFI Secure Boot Advanced Targeting), który jest obsługiwany przez GRUB2, shim i fwupd w najpopularniejszych dystrybucjach Linuksa. SBAT został opracowany wspólnie z firmą Microsoft i polega na dodaniu do plików wykonywalnych komponentów UEFI dodatkowych metadanych, które obejmują informacje o producencie, produkcie, komponencie i wersji. Określone metadane są certyfikowane podpisem cyfrowym i mogą być oddzielnie zawarte na listach dozwolonych lub zabronionych komponentów dla UEFI Secure Boot.
SBAT umożliwia blokowanie stosowania podpisów cyfrowych dla poszczególnych numerów wersji komponentów bez konieczności unieważniania kluczy dla Bezpiecznego rozruchu. Blokowanie podatności poprzez SBAT nie wymaga użycia listy odwołań certyfikatów UEFI (dbx), ale odbywa się na poziomie wymiany klucza wewnętrznego w celu wygenerowania podpisów i aktualizacji GRUB2, podkładki i innych artefaktów rozruchowych dostarczanych przez dystrybucje. Przed wprowadzeniem SBAT aktualizacja listy odwołań certyfikatów (dbx, UEFI Revocation List) była warunkiem całkowitego zablokowania luki, ponieważ osoba atakująca, niezależnie od używanego systemu operacyjnego, mogła użyć nośnika startowego ze starą, podatną na ataki wersją GRUB2, poświadczony podpisem cyfrowym, aby naruszyć bezpieczeństwo UEFI Secure Boot.
Źródło: opennet.ru