Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
U-Boot to jeden z najczęściej wykorzystywanych bootloaderów w urządzeniach wbudowanych, systemach IoT, kontrolerach BMC oraz wielu platformach przemysłowych i serwerowych. Odpowiada za uruchomienie systemu jeszcze przed startem jądra i usług bezpieczeństwa, dlatego każda podatność na tym etapie ma wyjątkowo wysoką wartość z perspektywy atakującego.
Najnowsze ustalenia badaczy pokazują, że sześć luk w mechanizmach weryfikacji obrazów FIT może osłabić lub obejść założenia verified boot i Secure Boot. W praktyce oznacza to ryzyko uruchomienia nieautoryzowanego kodu jeszcze przed startem systemu operacyjnego.
W skrócie
Badacze zidentyfikowali sześć podatności w U-Boot związanych z obsługą FIT, czyli formatu wykorzystywanego do pakowania i walidacji komponentów rozruchowych, takich jak jądro, device tree czy initramfs. Dwie z nich mogą prowadzić do wykonania dowolnego kodu, a cztery kolejne skutkują odmową usługi na etapie uruchamiania urządzenia.
- zagrożona jest ścieżka weryfikacji podpisów i integralności obrazów FIT,
- podatny kod był obecny od wersji v2013.07,
- problem może dotyczyć ponad 50 stabilnych wydań U-Boot,
- poprawki są już dostępne upstream, ale ich wdrożenie zależy od producentów firmware.
Kontekst / historia
Mechanizmy verified boot mają zapewniać, że każdy etap łańcucha rozruchowego uruchamia wyłącznie zaufany kod. Bootloader powinien więc nie tylko ładować obraz systemu, lecz także poprawnie sprawdzać jego integralność i podpis kryptograficzny. Jeśli jednak sama logika weryfikacyjna zawiera błędy pamięciowe lub walidacyjne, fundament zaufania przestaje działać.
To nie pierwszy przypadek, gdy bezpieczeństwo U-Boot i obsługi FIT budzi zastrzeżenia. Historia pokazuje, że kod odpowiedzialny za ochronę procesu startu może jednocześnie stanowić atrakcyjną powierzchnię ataku. Obecne ustalenia potwierdzają, że bootloader nadal pozostaje jednym z najbardziej krytycznych, a jednocześnie często niedostatecznie audytowanych elementów infrastruktury embedded.
Analiza techniczna
Wszystkie opisane luki aktywują się podczas przetwarzania obrazu FIT. Format Flattened Image Tree łączy różne komponenty firmware w jeden artefakt i zawiera metadane wykorzystywane do obliczania skrótów oraz weryfikacji podpisów. To właśnie ta ścieżka stała się źródłem sześciu odrębnych problemów bezpieczeństwa.
Dwie najgroźniejsze podatności dotyczą funkcji fdt_find_regions, używanej przy tworzeniu listy regionów przeznaczonych do haszowania. W jednym scenariuszu nieobsłużony zwrot wartości NULL z fdt_get_name może prowadzić do awarii, a w określonych warunkach także do przepełnienia bufora na stosie. Na niektórych platformach wbudowanych taki błąd może zostać przekształcony w wykonanie kodu jeszcze przed uruchomieniem systemu operacyjnego.
Druga luka opiera się na podobnym źródle problemu, ale skutkuje użyciem ujemnej długości podczas przesuwania wskaźnika w buforze stosu. Zamiast przesunięcia do przodu dochodzi do cofnięcia wskaźnika, co prowadzi do underflow i umożliwia nadpisanie danych kontrolnych, w tym potencjalnie adresu powrotu funkcji.
Pozostałe błędy mają charakter DoS, jednak w kontekście bootloadera ich wpływ jest nadal bardzo istotny. Jedna z luk wynika z braku walidacji pola hashed-strings, przez co możliwe jest wymuszenie haszowania danych poza granicami obrazu. Inna dotyczy zewnętrznie wskazywanych danych przez właściwości takie jak data-position, data-offset i data-size, które nie były poprawnie sprawdzane względem rzeczywistego rozmiaru FIT.
Kolejny problem to błędne użycie wskaźnika zwracanego przez fdt_get_property_by_offset, co prowadzi do dereferencji NULL. Ostatnia luka dotyczy nieograniczonej rekurencji w funkcji fdt_check_no_at podczas walidacji formatu FIT. Odpowiednio zagnieżdżona struktura drzewa może wyczerpać stos i zatrzymać proces bootowania.
Najważniejsze jest jednak to, że wszystkie te błędy pojawiają się przed uruchomieniem systemu operacyjnego i przed załadowaniem większości mechanizmów ochronnych. To sprawia, że ewentualna kompromitacja na tym poziomie jest szczególnie trudna do wykrycia i może funkcjonować poniżej warstwy widocznej dla klasycznych narzędzi bezpieczeństwa.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem podatności jest podważenie zaufanego łańcucha rozruchowego. Jeśli atakujący doprowadzi do wykonania kodu podczas weryfikacji FIT, może potencjalnie uruchomić nieautoryzowany firmware, osadzić trwały implant lub zmodyfikować zachowanie urządzenia na najwcześniejszym etapie startu.
Taka kompromitacja jest szczególnie niebezpieczna, ponieważ bywa odporna na tradycyjne metody detekcji i może wymagać fizycznego reflasha pamięci, aby całkowicie usunąć skutki ataku. Problem nie ogranicza się przy tym wyłącznie do scenariuszy z lokalnym lub fizycznym dostępem do sprzętu.
W środowiskach korzystających ze zdalnych aktualizacji firmware, interfejsów administracyjnych BMC lub mechanizmów OTA, luka w bootloaderze może zostać wykorzystana także przez przeciwnika mającego dostęp do procesu aktualizacji. Dotyczy to między innymi serwerów, urządzeń brzegowych, routerów, kamer IP oraz innych centralnie zarządzanych systemów embedded.
Nawet podatności klasy DoS mogą mieć wysoki wpływ operacyjny. W praktyce mogą powodować pętle restartu, trwałą niedostępność urządzenia lub utrudnienia w procedurach odzyskiwania, co jest szczególnie problematyczne w środowiskach OT, edge computing i data center.
Rekomendacje
Organizacje wykorzystujące urządzenia oparte na U-Boot powinny w pierwszej kolejności ustalić, czy ich sprzęt korzysta z FIT Signature Verification oraz które wersje bootloadera zostały zintegrowane z firmware dostawcy. Sama obecność U-Boot nie wystarcza do oceny ryzyka, ponieważ znaczenie ma również konfiguracja, model aktualizacji i ekspozycja interfejsów administracyjnych.
- przeprowadzić inwentaryzację urządzeń embedded, IoT, BMC i platform serwerowych korzystających z U-Boot,
- sprawdzić dostępność poprawek firmware u producentów sprzętu,
- nadać priorytet aktualizacjom systemów z funkcjami zdalnej aktualizacji i zewnętrznie dostępnymi interfejsami zarządzającymi,
- ograniczyć dostęp do mechanizmów aktualizacji firmware wyłącznie do zaufanych sieci i uprzywilejowanych kont,
- monitorować integralność firmware oraz zmiany w łańcuchu rozruchowym,
- przygotować procedury odzyskiwania i reflasha na wypadek kompromitacji bootloadera,
- wdrożyć segmentację sieci oraz dodatkową ochronę kontrolerów BMC i systemów zarządzania poza pasmem.
Z perspektywy producentów i integratorów firmware kluczowe jest szybkie backportowanie poprawek z gałęzi upstream, testy regresyjne ścieżki FIT oraz dodatkowe wzmocnienie walidacji danych wejściowych w kodzie parsującym FDT. Warto też ograniczać zestaw aktywnych funkcji bootloadera do minimum niezbędnego operacyjnie.
Podsumowanie
Nowe luki w U-Boot pokazują, że bezpieczeństwo bootloadera pozostaje jednym z najbardziej krytycznych obszarów cyberbezpieczeństwa urządzeń wbudowanych. Błędy w obsłudze FIT umożliwiają zarówno zatrzymanie procesu startu, jak i potencjalne wykonanie kodu jeszcze przed uruchomieniem systemu operacyjnego.
W praktyce oznacza to realne ryzyko osłabienia mechanizmów Secure Boot i verified boot w szerokim spektrum urządzeń. Dla zespołów bezpieczeństwa najważniejsze pozostają dziś trzy działania: identyfikacja podatnych zasobów, szybkie wdrażanie aktualizacji firmware oraz ograniczenie ekspozycji procesów zdalnej aktualizacji i zarządzania.
Źródła
- Security Affairs — https://securityaffairs.com/195150/security/critical-u-boot-bugs-undermine-secure-boot-on-millions-of-devices.html
- Binarly — Unfit to Boot: Breaking U-Boot’s FIT Signature Verification — https://www.binarly.io/blog/unfit-to-boot-breaking-u-boots-fit-signature-verification
- GitHub — binarly-io/Vulnerability-REsearch: BRLY-2026-042 — https://github.com/binarly-io/Vulnerability-REsearch/blob/main/U-Boot/BRLY-2026-042.md
- GitHub — u-boot/u-boot commit: image-fit: Limit recursion depth in fdt_check_no_at() — https://github.com/u-boot/u-boot/commit/9e0d2fb429657c6692a059ff18e427baf8046f12