25 luk w zabezpieczeniach RTOS Zephyr, w tym te wykorzystywane poprzez pakiet ICMP

Naukowcy z Grupy NCC opublikowane bezpłatne wyniki audytu projektu Zefir, rozwijający się system operacyjny czasu rzeczywistego (RTOS), mający na celu wyposażenie urządzeń zgodnych z koncepcją Internetu Rzeczy (IoT, Internet of Things). W trakcie kontroli wyszło na jaw 25 luk w zabezpieczeniach w Zephyr i 1 luka w MCUboot. Zephyr jest rozwijany przy udziale firm Intel.

W sumie zidentyfikowano 6 luk w stosie sieciowym, 4 w jądrze, 2 w powłoce poleceń, 5 w procedurach obsługi wywołań systemowych, 5 w podsystemie USB i 3 w mechanizmie aktualizacji oprogramowania sprzętowego. Dwie kwestie zostały ocenione jako krytyczne, dwie jako wysokie, 9 jako umiarkowane, 9 jako niskie, a 4 do rozważenia. Krytyczne problemy dotyczą stosu IPv4 i parsera MQTT, niebezpieczne dotyczą pamięci masowej USB i sterowników USB DFU. W momencie ujawnienia informacji przygotowano poprawki jedynie dla 15 najniebezpieczniejszych luk, a problemy prowadzące do odmowy usługi lub związane z wadami dodatkowych mechanizmów ochrony jądra pozostają nienaprawione.

W stosie IPv4 platformy zidentyfikowano lukę, którą można zdalnie wykorzystać. Prowadzi ona do uszkodzenia pamięci podczas przetwarzania zmodyfikowanych w określony sposób pakietów ICMP. Kolejny poważny problem został odnaleziony w parserze protokołu MQTT, który jest spowodowany brakiem prawidłowego sprawdzania długości pola nagłówka i może prowadzić do zdalnego wykonania kodu. Mniej poważne problemy z odmową usługi występują w stosie IPv6 i implementacji protokołu CoAP.

Inne problemy można wykorzystać lokalnie, aby spowodować odmowę usługi lub wykonanie kodu na poziomie jądra. Większość tych luk jest związana z brakiem odpowiedniego sprawdzania argumentów wywołań systemowych i może prowadzić do zapisywania i odczytywania dowolnych obszarów pamięci jądra. Problemy dotyczą także samego kodu przetwarzania wywołań systemowych — wywołanie ujemnego numeru wywołania systemowego powoduje przepełnienie liczby całkowitej. Jądro zidentyfikowało także problemy w implementacji zabezpieczenia ASLR (randomizacja przestrzeni adresowej) oraz mechanizmu ustawiania znaków kanaryjskich na stosie, przez co te mechanizmy są nieskuteczne.

Wiele problemów dotyczy stosu USB i poszczególnych sterowników. Na przykład problemy z pamięcią masową USB mogą spowodować przepełnienie bufora i wykonanie kodu na poziomie jądra, gdy urządzenie jest podłączone do hosta USB kontrolowanego przez atakującego. Luka w sterowniku USB DFU umożliwiającym ładowanie nowego oprogramowania sprzętowego przez USB umożliwia załadowanie zmodyfikowanego obrazu oprogramowania sprzętowego do wewnętrznej pamięci Flash mikrokontrolera bez użycia szyfrowania i z pominięciem trybu bezpiecznego rozruchu z weryfikacją komponentów przy użyciu podpisu cyfrowego. Dodatkowo zbadano kod otwartego programu ładującego MCUboot, w którym odkryto jedną łagodną lukę,
co może prowadzić do przepełnienia bufora podczas korzystania z protokołu SMP (Simple Management Protocol) przez UART.

Przypomnijmy, że w Zephyrze dla wszystkich procesów dostępna jest tylko jedna globalna współdzielona wirtualna przestrzeń adresowa (SASOS, Single Address Space Operating System). Kod specyficzny dla aplikacji jest łączony z jądrem specyficznym dla aplikacji, tworząc monolityczny plik wykonywalny, który można załadować i uruchomić na określonym sprzęcie. Wszystkie zasoby systemowe są określane w czasie kompilacji, co zmniejsza rozmiar kodu i zwiększa wydajność. Obraz systemu może zawierać tylko te funkcje jądra, które są wymagane do uruchomienia aplikacji.

Warto zauważyć, że wśród kluczowych zalet Zephyr wspomniane rozwój z myślą o bezpieczeństwie. Zatwierdzonyaby wszystkie etapy rozwoju przeszły obowiązkowymi etapami potwierdzania bezpieczeństwa kodu: testami fuzzingowymi, analizą statyczną, testami penetracyjnymi, przeglądem kodu, analizą implementacji backdoora i modelowaniem zagrożeń.

Źródło: opennet.ru

Dodaj komentarz