Secure Boot przepuszczał stare i podatne programy
Secure Boot ma sprawdzać każdy program uruchamiany podczas startu komputera. UEFI porównuje jego podpis z bazą zaufanych elementów oraz listą plików, które zostały unieważnione ze względów bezpieczeństwa.
Problem polegał na tym, że 11 starych programów typu shim wciąż miało ważny podpis Microsoftu i nie znajdowało się na liście blokowanych elementów. Były to głównie wersje 0.9 lub starsze, wykorzystywane między innymi przez dystrybucje Linuksa, narzędzia diagnostyczne i programy do zarządzania komputerami.
Shim jest niewielkim programem pełniącym funkcję pomostu między UEFI a kolejnym elementem odpowiedzialnym za uruchomienie systemu, takim jak GRUB 2. Pozwala to na przykład uruchamiać Linuksa przy włączonym Secure Boot bez konieczności dodawania kluczy każdej dystrybucji bezpośrednio do oprogramowania płyty głównej.
Sam mechanizm jest przydatny, ale w tym przypadku zaufaniem objęto również wyjątkowo stare wersje kodu. Co gorsza, atakujący nie musiał liczyć na to, że podatne oprogramowanie było już zainstalowane na komputerze. Mógł przynieść własną kopię podpisanego shima i wykorzystać ją na każdym urządzeniu ufającym certyfikatowi Microsoft Corporation UEFI CA 2011.
Złośliwy kod uruchamiał się przed Windowsem
Atak nie pozwalał na przejęcie dowolnego komputera jednym kliknięciem. Przestępca musiał wcześniej zdobyć uprawnienia administratora albo możliwość zmodyfikowania procesu rozruchu, na przykład przez dostęp do partycji systemowej EFI lub zewnętrznego nośnika.
Następnie mógł umieścić na komputerze stary shim wraz z podatnym programem GRUB 2. Ponieważ pierwszy plik nadal miał prawidłowy podpis Microsoftu, Secure Boot dopuszczał go do uruchomienia. Pozwalało to wykonać nieautoryzowany kod jeszcze przed załadowaniem Windowsa, Linuksa oraz większości programów antywirusowych.
Taki mechanizm mógł zostać wykorzystany do instalowania bootkitów UEFI, czyli złośliwego oprogramowania działającego na bardzo niskim poziomie. Bootkit może przetrwać ponowne uruchomienie komputera, a w niektórych przypadkach nawet reinstalację systemu.
Skąd wzięła się data 2013 roku?
Nie był to jeden konkretny błąd pozostający aktywny nieprzerwanie od 2013 roku. Badacze ustalili jednak, że programy i komponenty uznawane przez podatne shimy za zaufane były podpisywane lub kompilowane w latach 2013-2025.
Wśród wykorzystywanych problemów znalazły się więc podatności mające ponad dekadę. Jednym z przykładów jest błąd CVE-2015-5281 dotyczący GRUB-a 2. Całej sprawie przypisano również dwa nowe identyfikatory: CVE-2026-8863 oraz CVE-2026-10797.
Sednem problemu nie była zatem jedna zapomniana luka, lecz brak skutecznego wycofywania starych, podpisanych wcześniej programów. Choć ich producenci dawno wydali nowsze wersje, podatne pliki nadal mogły być uznawane przez Secure Boot za bezpieczne.
Dlaczego luka w Secure Boot jest ważna dla graczy?
Secure Boot coraz częściej przestaje być funkcją interesującą wyłącznie administratorów. Wymagają go między innymi niektóre współczesne systemy anti-cheat, które próbują utrudnić uruchamianie nieautoryzowanego kodu przed startem gry.
Na Game-Nest opisywaliśmy już, dlaczego aktualizacje Secure Boot w Windowsie 11 są istotne dla graczy PC. TPM 2.0 i Bezpieczny rozruch pojawiają się także w wymaganiach produkcji sieciowych, choć nie zawsze wystarczają do zatrzymania oszustów, co pokazały problemy z cheaterami w becie Call of Duty: Black Ops 7.
W praktyce luka nie oznacza, że Secure Boot jest całkowicie bezużyteczny. Pokazuje jednak, że skuteczność zabezpieczenia zależy nie tylko od jego włączenia, ale również od regularnego aktualizowania listy unieważnionych programów.
Microsoft zablokował 11 podatnych plików
ESET zgłosił odkrycie organizacji CERT/CC 16 lutego 2026 roku. Microsoft dodał 11 niebezpiecznych plików do bazy zabronionych podpisów DBX w ramach aktualizacji Patch Tuesday z 9 czerwca.
Użytkownicy Windowsa powinni otrzymać poprawkę automatycznie przez Windows Update. ESET zaleca zainstalowanie najnowszych aktualizacji systemowych oraz dostępnych aktualizacji UEFI lub BIOS-u. Nie należy natomiast wyłączać Secure Boot, ponieważ pozbawiłoby to komputer dodatkowej ochrony przed bootkitami.
Wycofanie 11 plików rozwiązuje bezpośrednio opisany problem, ale nie zamyka całej sprawy. Proces zatwierdzania shimów stał się bardziej przejrzysty dopiero w 2017 roku. Zdaniem ESET nie istnieje pełny katalog wszystkich starszych programów podpisanych wcześniej przez Microsoft, dlatego nie można wykluczyć, że podobne zapomniane pliki nadal pozostają zaufane.
Komentarze
Jeszcze nie ma komentarzy.