Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
U-Boot to jeden z najpowszechniej wykorzystywanych bootloaderów w urządzeniach wbudowanych, platformach IoT, routerach, kamerach, kontrolerach BMC oraz wybranych systemach serwerowych. Odpowiada za uruchomienie platformy jeszcze przed startem systemu operacyjnego, dlatego jego integralność stanowi fundament bezpieczeństwa całego łańcucha rozruchu.
Nowo ujawnione podatności pokazują, że błędy w obsłudze i weryfikacji obrazów FIT mogą osłabić założenia verified boot, a w określonych scenariuszach doprowadzić do awarii urządzenia lub nawet wykonania kodu na etapie pre-boot. To szczególnie niebezpieczne, ponieważ atak następuje poniżej warstw ochronnych systemu operacyjnego.
W skrócie
- Badacze zidentyfikowali sześć podatności w U-Boot związanych z przetwarzaniem obrazów FIT.
- Dwie luki mogą potencjalnie prowadzić do wykonania dowolnego kodu.
- Pozostałe błędy umożliwiają ataki typu denial-of-service przez zawieszenie lub awarię bootloadera.
- Problem dotyczy kodu obecnego od wersji v2013.07 i może obejmować dziesiątki stabilnych wydań.
- Zagrożenie jest istotne dla urządzeń korzystających z mechanizmów secure boot i verified boot.
Kontekst / historia
Mechanizm FIT Signature Verification w U-Boot służy do potwierdzania autentyczności oraz integralności komponentów ładowanych podczas rozruchu, takich jak kernel, initramfs, device tree czy inne elementy firmware. Jego zadaniem jest uniemożliwienie uruchomienia nieautoryzowanego lub zmodyfikowanego kodu.
To właśnie ten obszar ma krytyczne znaczenie dla modelu chain of trust. Jeżeli logika odpowiedzialna za weryfikację podpisu i walidację struktury obrazu zawiera błędy, podważone zostaje zaufanie do całego procesu startowego. Wcześniejsze incydenty związane z parserami FIT już pokazywały, że etap bootowania pozostaje jednym z najbardziej wrażliwych elementów stosu bezpieczeństwa.
Analiza techniczna
Opisane podatności koncentrują się wokół sposobu, w jaki U-Boot interpretuje struktury FIT oparte na FDT. Wspólnym problemem jest niewystarczająca walidacja danych wejściowych oraz niepełna kontrola wartości zwracanych przez funkcje parsujące.
Pierwsza grupa błędów dotyczy mechanizmu wyznaczania regionów haszowanych podczas weryfikacji podpisu. W określonych warunkach parser może operować na wartości NULL dla nazwy węzła bez wcześniejszego sprawdzenia jej poprawności. Taki scenariusz może skutkować awarią bootloadera, a w niektórych środowiskach również stworzyć warunki do nadpisania pamięci na stosie.
Druga istotna klasa problemów wynika z użycia ujemnych kodów błędów jako długości danych lub przesunięć wskaźników. Jeśli kod nie odróżnia wartości błędu od prawidłowego rozmiaru, może dojść do cofnięcia wskaźnika i underflow bufora. W praktyce otwiera to drogę do kontrolowanego nadpisania danych sterujących, w tym potencjalnie adresów powrotu funkcji.
Kolejne luki mają charakter denial-of-service i są związane z brakiem odpowiedniej kontroli granic oraz rozmiarów deklarowanych w metadanych obrazu FIT. Odpowiednio spreparowany obraz może zmusić bootloader do odczytu spoza dozwolonego obszaru pamięci, co kończy się awarią podczas haszowania lub walidacji.
Osobny problem dotyczy rekurencyjnego przechodzenia drzewa FIT bez skutecznego ograniczenia głębokości zagnieżdżenia. W efekcie złośliwie przygotowany obraz może doprowadzić do wyczerpania stosu jeszcze przed uruchomieniem systemu operacyjnego.
Najważniejszy wniosek techniczny jest prosty: jeśli parser obsługujący niezweryfikowany obraz FIT może zostać zakłócony przez spreparowane dane, to sam proces weryfikacji podpisu przestaje gwarantować bezpieczeństwo verified boot.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem jest możliwość naruszenia łańcucha zaufania jeszcze przed startem systemu operacyjnego. Udane wykorzystanie podatności prowadzącej do wykonania kodu może pozwolić napastnikowi osadzić złośliwą logikę w fazie rozruchu, co znacząco utrudnia wykrycie przez klasyczne rozwiązania bezpieczeństwa.
W środowiskach wykorzystujących kontrolery BMC ryzyko jest szczególnie wysokie. Jeżeli urządzenie obsługuje zdalne aktualizacje firmware lub udostępnia interfejsy administracyjne przez sieć, atak może nie wymagać fizycznego dostępu. To zwiększa prawdopodobieństwo trwałej kompromitacji firmware oraz wdrożenia mechanizmów persistence poniżej warstwy systemowej.
Nawet podatności skutkujące wyłącznie odmową usługi mają duże znaczenie operacyjne. W infrastrukturze przemysłowej, telekomunikacyjnej, edge computing i systemach krytycznych awaria bootloadera może oznaczać niedostępność usług, kosztowną interwencję serwisową oraz konieczność fizycznego odzyskiwania urządzenia.
Rekomendacje
Organizacje powinny w pierwszej kolejności ustalić, czy używany sprzęt korzysta z U-Boot oraz czy mechanizm FIT Signature Verification jest obecny w ścieżce rozruchu lub aktualizacji. Sama obecność U-Boot nie oznacza jeszcze pełnej ekspozycji, ale wymaga pilnej analizy.
- Zidentyfikować urządzenia wykorzystujące podatne wersje U-Boot, szczególnie w środowiskach BMC, IoT, edge i appliance.
- Monitorować komunikaty producentów oraz dostępność aktualizacji firmware zawierających poprawki upstream.
- Wdrażać poprawki wyłącznie z zaufanych kanałów i weryfikować integralność pakietów aktualizacyjnych.
- Ograniczyć dostęp sieciowy do interfejsów zarządzających, paneli serwisowych i mechanizmów zdalnej aktualizacji.
- Segmentować sieć administracyjną oraz stosować silne uwierzytelnianie do wszystkich ścieżek zarządzania.
- Uwzględnić bootloadery i komponenty firmware w procesie zarządzania podatnościami.
- Rozważyć testy bezpieczeństwa firmware, w tym analizę obrazów i walidację chain of trust.
Z perspektywy producentów i integratorów kluczowe pozostaje szybkie przenoszenie poprawek do gałęzi produktowych. W ekosystemie urządzeń wbudowanych opóźnienia między publikacją łatki a jej dostarczeniem klientowi końcowemu mogą być znaczące, co wydłuża okres realnej ekspozycji.
Podsumowanie
Nowe luki w U-Boot pokazują, że bezpieczeństwo rozruchu pozostaje jednym z najbardziej krytycznych obszarów nowoczesnej infrastruktury. Sześć błędów w obsłudze obrazów FIT, w tym dwa potencjalnie prowadzące do wykonania kodu, podważa zaufanie do mechanizmów secure boot i verified boot w szerokim spektrum urządzeń.
Dla zespołów bezpieczeństwa to wyraźny sygnał, że bootloadery i firmware muszą być traktowane jako pełnoprawny element powierzchni ataku. Skuteczna ochrona wymaga nie tylko aktualizacji, ale także lepszej inwentaryzacji, segmentacji dostępu i stałej kontroli integralności łańcucha rozruchu.
Źródła
- Security Affairs — https://securityaffairs.com/195150/security/critical-u-boot-bugs-undermine-secure-boot-on-millions-of-devices.html
- Binarly Advisories — https://www.binarly.io/advisories?cve=title
- U-Boot FIT Signature Verification Documentation — https://docs.u-boot.org/en/v2026.04/usage/fit/signature.html
- U-Boot Mailing List: Multiple vulnerabilities in the U-Boot FIT image signature verification logic — https://lists.denx.de/pipermail/u-boot/2026-May/619351.html
- Binarly Binary Risk Hunt — https://risk.binarly.io/