Wady BusyBox podkreślają potrzebę spójnych aktualizacji IoT.
Badacze bezpieczeństwa wykryli i zgłosili 14 luk w narzędziu przestrzeni użytkownika BusyBox, które jest używane w milionach urządzeń wbudowanych z oprogramowaniem układowym opartym na systemie Linux. Chociaż luki nie mają wysokiego poziomu krytyczności, niektóre z nich mogą potencjalnie spowodować zdalne wykonanie kodu (RCE).
BusyBox to pakiet oprogramowania narzędziowego, który jego twórcy opisują jako szwajcarski scyzoryk wbudowanego Linuksa. Zawiera implementacje najpopularniejszych narzędzi wiersza poleceń Linuksa, wraz z powłoką oraz klientem i serwerem DHCP, wszystkie spakowane jako pojedynczy plik binarny.
BusyBox stał się de facto standardem we wbudowanej przestrzeni użytkownika Linuksa, a jego samodzielny plik binarny obsługuje ponad 300 typowych poleceń Linuksa.
„Prawdopodobnie znajdziesz wiele urządzeń OT i IoT z BusyBox, w tym popularne programowalne kontrolery logiczne (PLC), interfejsy człowiek-maszyna (HMI) i zdalne jednostki końcowe (RTU) — z których wiele działa teraz w systemie Linux” — naukowcy ze specjalistycznej firmy DevOps JFrog powiedział w raporcie.
„Zbadaliśmy bazę danych JFrog zawierającą ponad 10 000 wbudowanych obrazów oprogramowania układowego […]. Odkryliśmy, że 40 procent z nich zawierało plik wykonywalny BusyBox, który jest powiązany z jednym z apletów, których dotyczy problem, co sprawia, że problemy te są niezwykle rozpowszechnione wśród wbudowanego oprogramowania układowego opartego na systemie Linux.
JFrog współpracował z naukowcami z firmy Claroty zajmującej się cyberbezpieczeństwem przemysłowym, aby przeanalizować BusyBox przy użyciu technik analizy statycznej i dynamicznej, w tym niestandardowego fuzzingu. Doprowadziło to do wykrycia luk w kilku popularnych apletach BusyBox: man (strony podręcznika), lzma/unlzma (kompresja), ash (powłoka), hush (powłoka) i awk (manipulacja tekstem/skrypty).
Odmowa usługi, wyciek informacji i RCE
Wszystkie 14 luk można wykorzystać do wywołania warunków odmowy usługi (DoS), takich jak nietypowe zużycie zasobów lub awarie procesów na urządzeniu. Podczas gdy DoS jest ogólnie postrzegany jako obarczony niższym ryzykiem w porównaniu z innymi rodzajami luk w zabezpieczeniach, w przypadku urządzeń takich jak sterowniki PLC i inne stosowane w środowiskach OT warunki DoS mogą zatrzymać krytyczne procesy przemysłowe.
To powiedziawszy, wykorzystywanie luk w apletach BusyBox zwykle wiąże się z możliwością kontrolowania danych wejściowych przetwarzanych przez te aplety w wyniku poleceń. To, czy można to zrobić zdalnie bez lokalnego dostępu do urządzenia, zależy od funkcji oferowanych przez urządzenie i sposobu ich implementacji.
Na przykład luka w man (CVE-2021-42373) ma zastosowanie, jeśli osoba atakująca może kontrolować wszystkie parametry przekazywane do polecenia man, aby mogła podać nazwę sekcji, ale nie podać argumentu strony.
Luki w ash (CVE-2021-42375) i hush (CVE-2021-42376 i CVE-2021-42377) są wynikiem niewłaściwej obsługi niektórych znaków specjalnych lub ciągów znaków w poleceniach powłoki. Wykorzystanie ich wymaga możliwości przekazywania specjalnie spreparowanych poleceń do powłok, a CVE-2021-42377 może również potencjalnie skutkować zdalnym wykonaniem kodu.
Luka w unlzma (CVE-2021-42374) może prowadzić do DoS lub wycieku informacji i może być wykorzystana poprzez przekazanie do apletu specjalnie spreparowanych danych wejściowych skompresowanych za pomocą LZMA.
Ta luka jest interesująca, ponieważ nawet jeśli sam aplet unlzma nie jest dostępny, inne aplety, takie jak tar, unzip, rpm, dpkg, lzma i man, używają podatnego kodu podczas obsługi plików z kompresją lzma, jeśli włączona jest opcja CONFIG_FEATURE_SEAMLESS_LZMA. Ta funkcja jest domyślnie włączona w BusyBox i znacznie rozszerza możliwe wektory ataku.
„Z punktu widzenia atakującego ZIP jest znacznie lepszym wektorem ataku, ponieważ wywołania rozpakowania są znacznie bardziej powszechne niż bezpośrednie wywołania unlzma” — stwierdzili naukowcy.
„Wyciek danych można wyodrębnić i zapisać w plikach, które można później odczytać zdalnie. Na przykład może się to zdarzyć we wbudowanej usłudze internetowej, która umożliwia przesyłanie plików ZIP z zasobami multimedialnymi, które zostaną rozpakowane w dostępnej lokalizacji. Stamtąd atakujący mógł odczytać dane z pamięci, które wyciekły”.
Pozostałe dziewięć luk znajduje się w awk i powoduje uszkodzenia pamięci po użyciu po zwolnieniu podczas przetwarzania specjalnie spreparowanych wzorców awk. Wszystkie mogą skutkować DoS i potencjalnie RCE.
„Luki typu use-after-free mogą być wykorzystane do zdalnego wykonania kodu, ale obecnie nie próbowaliśmy stworzyć dla nich exploita w postaci broni” – stwierdzili badacze. „Ponadto dość rzadkie (i z natury niebezpieczne) jest przetwarzanie wzorca awk z zewnętrznego wejścia”.
Luki zostały usunięte w BusyBox 1.34.0, dlatego zaleca się programistom oprogramowania układowego aktualizację do nowej wersji. Jeśli nie jest to możliwe z powodu problemów ze zgodnością, wcześniejszą wersję można skompilować bez wrażliwych apletów jako obejście.
Potrzeba regularnych aktualizacji
Wiele urządzeń IoT, OT i innych urządzeń wbudowanych przyjęło Linux jako system operacyjny z wyboru dla swojego oprogramowania układowego. W rezultacie używają również wielu z tysięcy narzędzi i usług typu open source, które składają się na ekosystem przestrzeni użytkownika Linuksa.
Niektóre z tych komponentów są obsługiwane przez duże społeczności programistów, podczas gdy niektóre mogą być obsługiwane przez bardzo małe zespoły lub nawet samotnych programistów.
We wszechobecnych składnikach systemu Linux przez cały czas wykrywane są luki, które mogą mieć wpływ na miliardy urządzeń. Chociaż aktualizowanie serwerów i komputerów stacjonarnych z systemem Linux można łatwo zautomatyzować, procesy aktualizacji w wielu systemach wbudowanych nadal wymagają ręcznej interwencji.
Nie wspominając o tym, że wielu programistów oprogramowania wbudowanego używa bardzo starych wersji zarówno jądra, jak i narzędzi przestrzeni użytkownika z różnych powodów kompatybilności.
Przedsiębiorstwa powinny stosować zasady instalowania poprawek, które uwzględniają ich urządzenia IoT i OT, i generalnie powinny wybierać urządzenia od dostawców, którzy zobowiązują się do wydawania regularnych i terminowych aktualizacji zabezpieczeń dla swoich produktów.
