W ostatnim czasie opisaliśmy kilka ciekawych luk w systemie Windows. Fani Linuksa pewnie zacierali wówczas ręce, ale dziś mamy złe wieści również dla nich. Niedawno ujawniona luka w poleceniu odczytu bootloadera GRUB2 (CVE-2025-0690) wzbudziła obawy dotyczące potencjalnego obejścia Secure Boot oraz uszkodzenia pamięci sterty w systemach Linux.
Kilka słów o Secure Boot
Secure Boot to mechanizm UEFI chroniący przed uruchamianiem niepodpisanego lub złośliwego kodu podczas startu systemu. Działa poprzez weryfikację cyfrowych podpisów bootloadera, jądra i sterowników względem zaufanych certyfikatów zapisanych w firmware. W systemach Linux najczęściej stosuje się Shim, podpisany bootloader, który uruchamia GRUB2 z obsługą Secure Boot. Choć zwiększa on bezpieczeństwo przed bootkitami i rootkitami, nie jest niezawodny – podatności, np. w GRUB2, mogą umożliwić jego obejście. Secure Boot można wyłączyć w UEFI, a w niektórych dystrybucjach wymaga on ręcznej konfiguracji.
Nowa luka w GRUB2 (CVE-2025-0690) a bezpieczeństwo Secure Boot
Red Hat Product Security ocenia tę lukę jako umiarkowanie poważną (CVSS v3.1: 6.1). Wymaga ona dostępu fizycznego, wysokich uprawnień i interakcji użytkownika, co ogranicza jej praktyczne wykorzystanie. Jednak skuteczny atak mógłby umożliwić wykonanie dowolnego kodu lub osłabienie zabezpieczeń Secure Boot, stanowiących kluczową linię obrony przed złośliwym oprogramowaniem na poziomie systemu operacyjnego i jądra.
Źródło podatności CVE-2025-0690
Luka wynika z błędu w obsłudze danych wejściowych klawiatury GRUB2, przetwarzanych przez polecenie odczytu. Problemem jest przechowywanie długości wejścia w 32-bitowej zmiennej całkowitej, co podczas iteracyjnej realokacji bufora może prowadzić do przepełnienia liczby całkowitej.
Gdy użytkownik wprowadzi bardzo duże wartości wejściowe, może dojść do zapisu poza zakresem w buforze opartym na stercie (CWE-787). W efekcie wewnętrzne struktury danych GRUB zostaną uszkodzone, co może doprowadzić do ominięcia weryfikacji podpisów Secure Boot i potencjalnego uruchomienia nieautoryzowanego kodu.
Zagrożone systemy i status poprawek
Luka dotyczy:
- Red Hat Enterprise Linux (RHEL) 9 (pakiet grub2),
- Red Hat OpenShift Container Platform 4 (komponent rhcos),
- starszych wersji, takich jak RHEL 7 i 8, które są teoretycznie podatne, ale nieobjęte już wsparciem Red Hat.
Wszystkie wcześniejsze wersje pakietów w tych produktach należy uznać za zagrożone, dopóki nie zostaną oficjalnie wykluczone z podatności.
Potencjalne konsekwencje ataku
Choć przeprowadzenie ataku jest trudne, jego skutki mogą być poważne. Możliwe scenariusze obejmują:
- Awarię systemu (typu odmowa usługi), gdy uszkodzenie pamięci spowoduje niestabilność GRUB2.
- Wykonanie dowolnego kodu, co może umożliwić trwałe naruszenie bezpieczeństwa procesu rozruchu.
- Przejęcie kontroli nad systemem, co narazi poufność, integralność i dostępność danych.
Luka łączy dwie kategorie podatności: CWE-190 (przepełnienie liczby całkowitej) oraz CWE-787 (zapis poza zakresem). Razem mogą one prowadzić do różnych wersji ataku, od zakłócenia działania systemu po jego pełne przejęcie.
Co mogą zrobić atakujący dzięki tej luce?
Secure Boot to kluczowy mechanizm ochrony przed złośliwym oprogramowaniem działającym na poziomie bootkitu oraz innymi zagrożeniami, które mogą naruszyć bezpieczeństwo systemu jeszcze przed jego pełną inicjalizacją. Jednak wykorzystując podatności w implementacji Secure Boot, atakujący mogliby:
- Nadpisać struktury pamięci GRUB, co pozwoliłoby na załadowanie niepodpisanych programów ładujących lub zmodyfikowanych jąder systemu, omijając weryfikację integralności.
- Ominąć mechanizmy sprawdzania podpisów, manipulując procedurami walidacyjnymi, co mogłoby umożliwić uruchomienie nieautoryzowanego kodu na etapie rozruchu.
- Ustanowić trwałe punkty zaczepienia (tzw. persistent footholds) przed inicjalizacją systemu operacyjnego, co mogłoby prowadzić do trwałego naruszenia bezpieczeństwa i ułatwiać dalszą eskalację uprawnień.
Choć ataki tego rodzaju są skomplikowane technicznie i wymagają zaawansowanej wiedzy, ich potencjalne skutki mogą być szczególnie groźne w środowiskach o wysokim poziomie bezpieczeństwa lub współdzielonych, gdzie dostęp fizyczny do urządzeń jest ograniczony. W takich przypadkach skuteczna eksploitacja może pozwolić na przejęcie pełnej kontroli nad systemem i ominięcie tradycyjnych mechanizmów obronnych.
Red Hat podkreśla, że eksploatacja podatności Secure Boot prawdopodobnie wymagałaby wielostopniowego ataku, obejmującego m.in. inżynierię społeczną, aby wprowadzić ofiarę w błąd i skłonić ją do uruchomienia zainfekowanego oprogramowania, oraz eskalację uprawnień, co umożliwiłoby wykonanie złośliwego kodu na poziomie rozruchu. W praktyce może to oznaczać manipulację certyfikatami, kompromitację łańcucha zaufania lub wykorzystanie błędów w implementacji ładowarek systemowych.
Jak sobie radzić z problemem?
Opisywana luka pokazuje, że bezpieczeństwo bootloadera wciąż wiąże się z wyzwaniami, takimi jak:
- Trudne zarządzanie pamięcią w niskopoziomowym oprogramowaniu, gdzie błędy mogą prowadzić do luk w zabezpieczeniach.
- Stary kod w GRUB2, który musi obsługiwać zarówno nowoczesny sprzęt i UEFI, jak i starsze rozwiązania, co zwiększa ryzyko błędów.
- Słabe ogniwa w łańcuchu zaufania, które mogą zostać wykorzystane do obejścia mechanizmów ochronnych przed uruchomieniem systemu.
Eksperci podkreślają, że społeczność Linuksa musi pracować nad bezpieczniejszymi bootloaderami, np. opartymi na Rust, który lepiej chroni pamięć. Jednak przejście na nowe rozwiązania zajmie jeszcze sporo czasu.
Coraz bardziej zaawansowane ataki na firmware pokazują, że nawet sprawdzone systemy open source wymagają stałej kontroli i ulepszania zabezpieczeń.