Krytyczna podatność w telnetd

Początkowo informacja na temat wykrycia (kolejnej) podatności w Telnetd przeszła bez echa. Wszak Telnet to bardzo stary protokół. Niska popularność rozwiązania może tłumaczyć, dlaczego problem początkowo nie wzbudził większego zainteresowania…

TLDR:

• Krytyczna podatność w telnetd obecna w kodzie od 1994 roku. Ocena 9.8 w CVSS 3.1, jednak tym razem nie musi to oznaczać końca świata.
• Możliwość wykorzystania luki w realnych warunkach silnie zależy od lokalnych zależności. Testy watchTowr wykazały, że stworzenie uniwersalnego, łatwego w użyciu exploita jest praktycznie niemożliwe.

Telnet to rozwiązanie, które swoje największe triumfy święciło w czasach, kiedy nikomu jeszcze nie śnił się powszechny dostęp do wspólnej sieci. Telnet umożliwia wykonywanie poleceń na zdalnym serwerze za pośrednictwem połączenia TCP/IP. Typowa konfiguracja zakłada konieczność uwierzytelniania przed uzyskaniem dostępu do powłoki systemu. Jedną z istotnych cech Telnetu jest to, że nie jest szyfrowany, a co za tym idzie, dane przesyłane za jego pośrednictwem, włącznie z loginem i hasłem, mają formę jawną. Już wiele lat temu w powszechnym użyciu z powodzeniem został zastąpiony przez SSH. Nie oznacza to jednak, że znaczenie problemu jest marginalne. Sprawa wydaje jest bardziej złożona, dlatego warto przyjrzeć się jej bliżej.

Podatność oznaczona identyfikatorem CVE-2026-32746 została odkryta przez DREAM Security Research Team. W CVSS 3.1 otrzymała wysoką ocenę 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). MITRE klasyfikuje to jako CWE-120. NVD opisuje problem jako out-of-bounds write w obsłudze procedury negocjacji LINEMODE SLC (Set Linemode Characters), spowodowany brakiem sprawdzania, czy bufor jest już pełny. Skutkuje to możliwością wysłania specjalnie przygotowanych danych jeszcze przed uwierzytelnieniem. Takie dane serwer zapisze poza granicami bufora. Na blogu watchTowr luka została opisana jako BSS-based buffer overflow (czyli przepełnienie dotyczące globalnej tablicy lub innego obiektu danych umieszczonego w segmencie BSS) zdolny do nadpisania około 400 bajtów sąsiednich zmiennych. Taki atak polega na wprowadzeniu do bufora większej ilości danych niż przewidziano, przez co nadpisywana jest sąsiednia pamięć procesu. W typowych sytuacjach może to doprowadzić do zmiany działania programu lub nawet jego awarii, jednak bardziej świadome wykorzystanie tego mechanizmu może umożliwić także wykonanie dowolnego kodu, a w efekcie nawet przejęcie kontroli nad całym systemie. Natomiast funkcja LINEMODE sprawia, że dane wpisywane w terminalu nie są przesyłane znak po znaku, lecz w większych paczkach, dzięki czemu przesłanie jednego wiersza generuje jedynie kilka pakietów w przeciwieństwie do typowej sytuacji, kiedy kilka pakietów generuje przesłanie jednego znaku. Taki sposób organizacji łączności pozwala ograniczyć ilość przesyłanych danych. Dodatkowo szczególnie w sieciach, gdzie występują duże opóźnienia, pozwala zwiększyć odczuwalną responsywność samego terminala. Jak widać, mamy do czynienia z rozwiązaniem z minionej epoki, projektowanym w czasach, kiedy liczył się każdy przesłany bit. Co ważne, w 2005 roku podobny problem został wykryty także w części klienckiej oprogramowania. W tym przypadku problem również polegał na niewłaściwej kontroli granic.

Najważniejsze jest jednak właściwe określenie skali zagrożenia. Zespół watchTowr zwraca uwagę, że nie jest to łatwe. Podatny kod może być obecny w różnych forkach; szczególnie starszych, osadzonych systemach, które nie są już aktywnie utrzymywane. Dotknięty błędem telnetd występuje w większości popularnych systemów operacyjnych, jednak nie jest to jedyna implementacja serwera protokołu Telnet. Szacuje się, że większość dostawców oparła implementacje swoich serwerów  na kodzie pochodzącego z GNU inetutils Telnetd, przez co pełne określenie możliwego zasięgu rażenia wydaje się niemożliwe. Trudno stwierdzić, jak często wykorzystywany jest Telnet w 2026 roku, jednak jak zwracają uwagę Autorzy wpisu, może to być znacznie częstsze niż mogłoby się to komukolwiek wydawać. Środowiska OT, ICS i embedded często opierają się na sprzęcie o ograniczonych zasobach, z niewspieranym od lat oprogramowaniem i zależnym od kompatybilności ze starszymi rozwiązaniami. W takich przypadkach aktualizacja oprogramowania często wiąże się z koniecznością poważnych przestojów, a nierzadko także dużych inwestycji w sprzęt, które pod względem biznesowym często uznawane są za nieuzasadnione. Wszędzie tam może być wykorzystywany podatny serwer Telnet. To wszystko w połączeniu z niewystarczającą segmentacją zasobów sieciowych może stanowić realny problem bezpieczeństwa.

Obserwowana rozbieżność między wysoką oceną podatności a brakiem gotowego exploita skłoniła badaczy z watchTowr do głębszej analizy zagadnienia. Podatność otrzymała krytyczną ocenę w CVSS 3.1 wynoszącą 9.8 i sprowadza się do zdalnie osiągalnego zapisu poza bufor, jednak jej wykorzystanie zależy od konkretnej architektury, kompilacji i układu pamięci w danym systemie, co jest typowe dla błędu tej klasy. Na podstawie przeprowadzonych testów można dostrzec różnice w zachowaniu w systemach 64- i 32-bitowych. Ograniczenia występujące w 64-bitowych systemach związane z rozmiarem wskaźników i układem bajtów znacząco utrudniają pełne nadpisanie pamięci, gdy tymczasem na systemach z 32-bitową architekturą pojawiają się bardziej użyteczne gadżety. W efekcie podatność należy traktować jako potencjalnie realne i poważne zagrożenie, ale nie jako uniwersalny scenariusz ataku.

Nie jest to pierwszy raz, kiedy ocena CVSS odbiega od subiektywnych odczuć co do faktycznego wpływu podatności na bezpieczeństwo. Stare technologie pozostaną z nami jeszcze długo, czego najlepszym dowodem jest zamieszczony powyżej zrzut ekranu z serwisu Shodan ukazujący wyłącznie widoczne z internetu serwery Telnet (kto wie, ile serwerów pozostaje uruchomionych w wewnętrznych sieciach). Co prawda nie jest obecnie znany uniwersalnie działający exploit, a testy przeprowadzone przez badaczy z watchTowr pokazały, że stworzenie takowego jest wysoce nietrywialne oraz wymaga ścisłego sprofilowania pod dane środowisko. Niemniej jednak skutki takiej udanej eksploitacji mogą być opłakane (jak wskazano w raporcie Censys, Telnetd często działa jako root w ramach inetd/xinetd, więc skuteczne wykorzystanie może oznaczać pełne przejęcie systemu, szczególnie w systemach wbudowanych i tam, gdzie mechanizmy ochrony pamięci są niewystarczające). Stąd też opieszałość w wydawaniu poprawek bezpieczeństwa dla telnetd wydaje się niezrozumiała. W momencie powstawania tego artykułu większość popularnych dystrybucji nie wydała jeszcze stosownych aktualizacji. Poprawki (z zauważalnym opóźnieniem) udostępniły już Debian i SUSE. Red Hat poinformował, że podatność nie wpływa na pakiety zawarte w ich repozytorium. Ponadto w dalszym ciągu podatne są źródła udostępniane w zasobach GNU. Warto zapoznać się z drobiazgową, bardzo techniczną analizą zagadnienia na blogu watchTowr oraz z raportem Censys.

Źródło: watchTwor, Censys

~pu