Odkryto dwie luki w bootloaderze GRUB2, które mogą prowadzić do wykonania kodu przy użyciu specjalnie przygotowanych czcionek oraz przetwarzaniu określonych sekwencji Unicode. Luki mogą być wykorzystywane do obejścia mechanizmu zweryfikowanego uruchamiania UEFI Secure Boot.
Zidentyfikowane luki:
- CVE-2022-2601 — przepełnienie bufora w funkcji grub_font_construct_glyph() przy przetwarzaniu specjalnie przygotowanych czcionek w formacie pf2, które występuje z powodu błędnego obliczenia parametru max_glyph_size i przydzielenia obszaru pamięci, który jest wyraźnie mniejszy niż potrzebny do pomieszczenia glifów.
- CVE-2022-3775 — zapis poza przydzielony obszar pamięci podczas renderowania niektórych sekwencji Unicode przy użyciu specjalnie przygotowanej czcionki. Problem ten występuje w kodzie przetwarzania czcionek i jest spowodowany brakiem odpowiednich sprawdzeń zgodności szerokości i wysokości glifu z rozmiarem istniejącego bitmapy. Atakujący może dobrać dane wejściowe w taki sposób, aby spowodować zapis danych poza przydzielonym buforem. Zauważono, że pomimo trudności w wykorzystaniu luk, osiągnięcie wykonania kodu nie jest wykluczone.
Poprawka została opublikowana w postaci łatki. Status usunięcia luk w dystrybucjach można ocenić na tych stronach: Ubuntu, SUSE, RHEL, Fedora, Debian. W celu rozwiązania problemów w GRUB2 nie wystarczy po prostu zaktualizować pakiet, konieczne będzie także stworzenie nowych wewnętrznych podpisów cyfrowych oraz aktualizacja instalatorów, bootloaderów, pakietów jądra, fwupd i warstwy shim.
W większości dystrybucji Linuxa do zweryfikowanego uruchamiania w trybie UEFI Secure Boot używa się małej warstwy shim, podpisanej cyfrowo przez firmę Microsoft. Ta warstwa weryfikuje GRUB2 własnym certyfikatem, co pozwala deweloperom dystrybucji unikać podpisywania każdego aktualizowanego jądra i GRUB w Microsoft. Luki w GRUB2 pozwalają na wykonanie własnego kodu na etapie po pomyślnej weryfikacji shim, ale przed załadowaniem systemu operacyjnego, wkraczając w łańcuch zaufania w aktywnym trybie Secure Boot, co daje pełną kontrolę nad dalszym procesem uruchamiania, w tym nad uruchomieniem innego systemu operacyjnego, modyfikacją komponentów systemu operacyjnego i omijaniem zabezpieczeń 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
