Luki w zabezpieczeniach FreeBSD, IPnet i Nucleus NET związane z błędami w implementacji kompresji DNS

Grupy badawcze Forescout Research Labs i JSOF Research opublikowały wyniki wspólnego badania bezpieczeństwa różnych implementacji schematu kompresji używanego do pakowania zduplikowanych nazw w wiadomościach DNS, mDNS, DHCP i IPv6 RA (pakowanie zduplikowanych części domen w wiadomościach zawierające wiele nazw). W trakcie prac zidentyfikowano 9 podatności, które podsumowano pod kryptonimem NAZWA:WRECK.

Zidentyfikowano problemy we FreeBSD, a także w podsystemach sieciowych IPnet, Nucleus NET i NetX, które rozpowszechniły się w systemach operacyjnych czasu rzeczywistego VxWorks, Nucleus i ThreadX stosowanych w urządzeniach automatyki, pamięci masowej, urządzeniach medycznych, awionice, drukarkach i elektroniki użytkowej. Szacuje się, że luki dotyczą co najmniej 100 milionów urządzeń.

  • Luka w zabezpieczeniach FreeBSD (CVE-2020-7461) umożliwiła zorganizowanie wykonania jego kodu poprzez wysłanie specjalnie zaprojektowanego pakietu DHCP do atakujących znajdujących się w tej samej sieci lokalnej co ofiara, którego przetworzenie przez podatnego na ataki klienta DHCP doprowadziło do do przepełnienia bufora. Problem został złagodzony przez fakt, że proces dhclient, w którym występowała luka, działał z uprawnieniami do resetowania w izolowanym środowisku Capsicum, co wymagało zidentyfikowania innej luki w celu jego zakończenia.

    Istota błędu polega na nieprawidłowym sprawdzeniu parametrów w pakiecie zwróconym przez serwer DHCP z opcją DHCP 119, która umożliwia przesłanie listy „wyszukiwania domen” do resolwera. Nieprawidłowe obliczenie rozmiaru bufora wymaganego do umieszczenia rozpakowanych nazw domen doprowadziło do zapisania informacji kontrolowanych przez osobę atakującą poza przydzielonym buforem. We FreeBSD problem został rozwiązany we wrześniu ubiegłego roku. Problem można wykorzystać tylko wtedy, gdy masz dostęp do sieci lokalnej.

  • Luka we wbudowanym stosie sieci IPnet używanym w RTOS VxWorks umożliwia potencjalne wykonanie kodu po stronie klienta DNS w wyniku niewłaściwej obsługi kompresji wiadomości DNS. Jak się okazało, luka ta została po raz pierwszy zidentyfikowana przez Exodus w 2016 roku, ale nigdy nie została naprawiona. Nowa prośba do Wind River również pozostała bez odpowiedzi, a urządzenia IPnet pozostają podatne na ataki.
  • W stosie TCP/IP Nucleus NET, obsługiwanym przez firmę Siemens, zidentyfikowano sześć luk w zabezpieczeniach, z których dwie mogą prowadzić do zdalnego wykonania kodu, a cztery mogą prowadzić do odmowy usługi. Pierwszy niebezpieczny problem związany jest z błędem podczas dekompresji skompresowanych wiadomości DNS, natomiast drugi związany jest z nieprawidłowym analizowaniem etykiet nazw domen. Obydwa problemy powodują przepełnienie bufora podczas przetwarzania specjalnie sformatowanych odpowiedzi DNS.

    Aby wykorzystać luki, osoba atakująca musi po prostu wysłać specjalnie zaprojektowaną odpowiedź na każde uzasadnione żądanie wysłane z podatnego urządzenia, na przykład przeprowadzając atak MTIM i zakłócając ruch pomiędzy serwerem DNS a ofiarą. Jeśli atakujący ma dostęp do sieci lokalnej, może uruchomić serwer DNS, który próbuje zaatakować problematyczne urządzenia, wysyłając żądania mDNS w trybie rozgłoszeniowym.

  • Luka w stosie sieciowym NetX (Azure RTOS NetX), stworzona dla ThreadX RTOS i otwarta w 2019 roku po przejęciu przez Microsoft, ograniczała się do odmowy usługi. Problem jest spowodowany błędem podczas analizowania skompresowanych wiadomości DNS w implementacji modułu rozpoznawania nazw.

Spośród przetestowanych stosów sieciowych, w których nie stwierdzono podatności związanych z kompresją powtarzających się danych w wiadomościach DNS, wyróżniono projekty: lwIP, Nut/Net, Zephyr, uC/TCP-IP, uC/TCP-IP, FreeRTOS+TCP , OpenThread i FNET. Co więcej, pierwsze dwa (Nut/Net i lwIP) w ogóle nie obsługują kompresji w wiadomościach DNS, podczas gdy pozostałe realizują tę operację bez błędów. Ponadto należy zauważyć, że wcześniej ci sami badacze zidentyfikowali już podobne luki w stosach Treck, uIP i PicoTCP.

Źródło: opennet.ru

Dodaj komentarz