Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Mechanizm Secure Boot został zaprojektowany po to, aby podczas uruchamiania systemu wykonywane były wyłącznie zaufane i poprawnie podpisane komponenty. W praktyce ma to chronić urządzenia przed uruchomieniem złośliwego kodu jeszcze przed startem systemu operacyjnego.
Najnowsze ustalenia badaczy pokazują jednak, że bezpieczeństwo tego modelu może zostać osłabione przez stare wersje UEFI shim. Są to niewielkie loadery rozruchowe, powszechnie używane przede wszystkim w ekosystemie Linuksa. Problem polega na tym, że część historycznych, podatnych shimów przez długi czas pozostawała podpisana i zaufana, co otwierało drogę do obejścia Secure Boot.
W skrócie
- Badacze wskazali, że niemal tuzin starych shimów UEFI podpisanych przez Microsoft mógł zostać użyty do obejścia Secure Boot.
- Największe ryzyko dotyczyło bardzo starych wersji, zwłaszcza shim 0.9 i wcześniejszych.
- W czerwcu 2026 roku podatne komponenty zostały unieważnione i dodane do bazy UEFI DBX.
- Z problemem powiązano luki CVE-2026-8863 oraz CVE-2026-10797.
- Zagrożone były systemy ufające certyfikatowi Microsoft Corporation UEFI CA 2011, niezależnie od zainstalowanego systemu operacyjnego.
Kontekst / historia
Shim pełni rolę pośrednika między firmware UEFI a dalszymi elementami procesu uruchamiania, takimi jak GRUB czy jądro systemu. Dzięki temu dystrybucje Linuksa mogą korzystać z istniejącego modelu zaufania opartego na podpisach Microsoft, bez potrzeby ręcznego dodawania własnych kluczy do pamięci urządzenia.
Przez lata projekt shim był rozwijany i poprawiany, a kolejne wersje usuwały znane problemy bezpieczeństwa. Kłopot pojawił się jednak po stronie bardzo starych buildów, które zostały podpisane w przeszłości i nadal były akceptowane przez platformy korzystające z Secure Boot. Część z nich pochodziła jeszcze sprzed bardziej uporządkowanego procesu zatwierdzania i dokumentowania podpisanych shimów, który funkcjonuje od 2017 roku.
W efekcie historyczne binaria, choć od dawna nieaktualne, pozostały elementem aktywnego łańcucha zaufania. To właśnie ten odziedziczony komponent okazał się słabym punktem całego mechanizmu.
Analiza techniczna
Atak bazuje na tym, że platforma ufa podpisanemu shimowi. Jeżeli stary loader nie został dodany do listy unieważnień DBX, a jego podpis nadal jest uznawany za ważny, może zostać użyty jako pierwszy etap uruchomienia. Następnie taki shim jest w stanie załadować kolejne komponenty rozruchowe zgodne z jego własnym modelem zaufania.
To oznacza, że napastnik nie musi od razu łamać współczesnych zabezpieczeń firmware. Wystarczy wykorzystać legalnie podpisany, lecz przestarzały komponent, który otworzy drogę do dalszych, słabiej chronionych elementów łańcucha startowego. W praktyce problem dotyczy więc nie pojedynczego pliku, ale całego historycznego łańcucha zależności i zaufania.
Szczególnie groźny jest scenariusz określany jako „bring your own vulnerable shim”. Polega on na dostarczeniu własnego, starego i poprawnie podpisanego shima, który nadal jest akceptowany przez platformę. Taki komponent może następnie posłużyć do zbudowania alternatywnego łańcucha rozruchowego i uruchomienia kodu, który normalnie zostałby zablokowany przez Secure Boot.
Dodatkowym ryzykiem jest możliwość wykorzystania innych historycznych komponentów akceptowanych przez stare shimy. Jeśli zawierają one znane podatności, napastnik może odtworzyć dawne ścieżki ataku i uruchomić własny kod jeszcze przed startem systemu operacyjnego.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem jest możliwość wykonania nieautoryzowanego kodu na etapie rozruchu. Taki dostęp stwarza warunki do instalacji bootkitów, trwałego ukrywania złośliwego oprogramowania oraz omijania zabezpieczeń, które uruchamiają się dopiero po załadowaniu systemu.
Problem nie ogranicza się wyłącznie do komputerów użytkowników końcowych. Ryzyko dotyczy także serwerów fizycznych, środowisk zwirtualizowanych i infrastruktury chmurowej, gdzie zaufane komponenty rozruchowe również odgrywają kluczową rolę. W dużych organizacjach oznacza to wyzwanie zarówno bezpieczeństwa, jak i ciągłości działania.
Wdrożenie unieważnień DBX w niewłaściwej kolejności może bowiem doprowadzić do problemów z uruchamianiem systemów. Jeżeli administratorzy zablokują stare komponenty przed aktualizacją zaufanych elementów rozruchowych, część środowiska może przestać startować poprawnie. Dlatego ten typ zagrożenia wymaga bardzo ostrożnego planowania zmian.
Rekomendacje
Organizacje powinny rozpocząć od pełnej inwentaryzacji komponentów wykorzystywanych w łańcuchu rozruchowym. Dotyczy to przede wszystkim shimów, bootloaderów, certyfikatów oraz obrazów systemowych używanych na stacjach roboczych, serwerach i maszynach wirtualnych.
Kluczowe znaczenie ma prawidłowa kolejność działań. Najpierw należy wdrożyć aktualne i bezpieczne komponenty rozruchowe, a dopiero później zastosować wpisy unieważniające w bazie DBX. Taka sekwencja zmniejsza ryzyko przerwania procesu bootowania.
- aktualizować firmware UEFI oraz bazę DBX zgodnie z zaleceniami producentów,
- usuwać z repozytoriów i obrazów systemowych przestarzałe shimy oraz stare bootloadery,
- testować zmiany Secure Boot na reprezentatywnej grupie urządzeń przed wdrożeniem produkcyjnym,
- monitorować integralność komponentów EFI i partycji rozruchowych,
- przygotować procedury odzyskiwania po nieudanych aktualizacjach rozruchu,
- sprawdzić, czy narzędzia do provisioningu, golden images oraz mechanizmy PXE nie dystrybuują starych binariów.
Z perspektywy operacyjnej warto również uwzględnić komponenty bootujące w procesach hardeningu oraz zarządzania podatnościami. W przeciwnym razie historyczne, podpisane pliki mogą pozostać niewidoczną furtką w infrastrukturze.
Podsumowanie
Sprawa starych shimów UEFI pokazuje, że skuteczność Secure Boot zależy nie tylko od samej funkcji w firmware, ale od kondycji całego łańcucha zaufania. Nawet formalnie włączona ochrona może zostać podważona, jeśli platforma nadal akceptuje historyczne, podatne i podpisane komponenty.
Dla firm i administratorów to wyraźny sygnał, że przegląd elementów rozruchowych powinien być stałą częścią strategii bezpieczeństwa. W praktyce bezpieczeństwo startu systemu jest tak silne, jak najsłabszy nadal zaufany komponent obecny w środowisku.