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. Status poprawek luk w zabezpieczeniach w dystrybucjach można sprawdzić na tych stronach: Ubuntu, SUSE, RHEL, Fedora, DebianNaprawianie problemów z GRUB2 wymaga czegoś więcej niż tylko aktualizacji pakietu. Konieczne jest również wygenerowanie nowych wewnętrznych podpisów cyfrowych oraz zaktualizowanie instalatorów, programów ładujących, 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, w tym nad uruchomieniem innego systemu operacyjnego, modyfikacją komponentów systemu operacyjnego i ominięciem 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 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
