Уязвимость в GNU Inetutils Telnetd: Исследователи обнаружили два новых способа получения прав root через 27-летнюю ошибку

В конце января сообщество специалистов по информационной безопасности столкнулось с критической уязвимостью (CVE-2026-24061) в сервере telnetd, входящем в набор GNU Inetutils. Эта уязвимость позволяла удалённому злоумышленнику подключиться к системе под учётной записью суперпользователя (root) без необходимости ввода пароля. Однако, как выяснилось, история на этом не закончилась. Новые исследования, проведённые независимо друг от друга, выявили целый комплекс проблем, уходящих корнями в неполное исправление уязвимости CVE-1999-0073, обнаруженной в далёком 1999 году. Эти уязвимости позволяют непривилегированному локальному пользователю повысить свои права до уровня администратора системы, что ставит под угрозу целостность тысяч систем, особенно в корпоративных и образовательных сегментах, где устаревший протокол telnet всё ещё может использоваться для управления сетевым оборудованием или историческими системами.

Детали уязвимости

Суть проблемы кроется в фундаментальном механизме работы telnet-сервера. Протокол telnet предусматривает возможность для клиента передавать на сервер переменные окружения с помощью опции ENVIRON. Эти переменные, заданные извне, устанавливаются в окружении самого процесса telnetd, который, как правило, работает с привилегиями root. В свою очередь, все дочерние процессы, запускаемые telnetd, включая критически важный "/bin/login", наследуют это окружение. Исходная уязвимость CVE-1999-0073 заключалась в том, что клиент мог передать переменную "LD_LIBRARY_PATH", заставлявшую динамический компоновщик загружать указанную злоумышленником библиотеку при запуске login. Это открывало путь для выполнения произвольного кода с правами суперпользователя.

После публикации информации о CVE-2026-24061 разработчики GNU Inetutils попытались исправить ситуацию, добавив фильтрацию опасных переменных по чёрному списку. Были заблокированы переменные, начинающиеся с префиксов "LD_", "_RLD_", а также конкретные имена, такие как "LIBPATH", "ENV" и "IFS". Однако, как обнаружил исследователь Рон Бен Ицхак из компании SafeBreach, в этом списке не оказалось переменной "CREDENTIALS_DIRECTORY". Данная переменная обрабатывается утилитой "/usr/bin/login" из набора util-linux и предназначена для указания альтернативного каталога с файлами учётных данных. Если в указанном каталоге существует файл с именем "login.noauth", содержащий строку "yes", процесс login пропускает этап аутентификации паролем. Атакующий, имеющий учётную запись на целевой системе, может создать в своём домашнем каталоге подкаталог, поместить туда файл "login.noauth" с нужным содержимым и, подключившись через telnet, передать переменные "CREDENTIALS_DIRECTORY" (указывающую на созданный каталог) и "USER=root". В результате сервер telnetd, не проверив пароль, предоставит оболочку с правами суперпользователя.

1	./telnet_lpe.py 127.0.0.1 --env CREDENTIALS_DIRECTORY=/home/weak_user/fake_cred --env USER=root

Между тем, почти параллельно другой исследователь, Джастин Сварц, провёл более глубокий анализ и пришёл к выводу, что проблема носит системный характер и не ограничивается одной пропущенной переменной. Он подтвердил, что попытка исправления уязвимости 1999 года с помощью чёрного списка потерпела неудачу. Ключевая проблема заключается в том, что процесс "/bin/login" запускается telnetd в так называемом контексте "root-to-root". Это означает, что ядро устанавливает для процесса флаг "AT_SECURE" в ноль, отключая встроенные механизмы безопасности динамического компоновщика (ld-linux.so) и стандартной библиотеки C (glibc), которые в ином случае игнорировали бы или обезвреживали опасные переменные окружения. Таким образом, вся ответственность за очистку окружения ложится на код telnetd, и подход с чёрным списком признан несостоятельным.

Джастин Сварц продемонстрировал ещё один, более изощрённый вектор атаки, использующий особенности библиотек GNU gettext и glibc. Он показал, что, передав через telnet переменные окружения "OUTPUT_CHARSET" и "LANGUAGE", можно заставить библиотеку gettext, отвечающую за интернационализацию, инициировать преобразование кодировки символов. Это преобразование, в свою очередь, вызывает функцию "iconv_open()" из glibc. Поскольку флаг "AT_SECURE" не установлен, функция "iconv_open()" будет искать файл конфигурации "gconv-modules", используя путь, указанный в переменной окружения "GCONV_PATH". Злоумышленник, имеющий возможность записывать файлы в систему (например, через ту же низкоуровневую учётную запись), может создать поддельный каталог ".gconv" в своём домашнем каталоге, поместить туда управляющий файл "gconv-modules" и вредоносную разделяемую библиотеку. При следующем подключении через telnet и передаче нужного набора переменных ("GCONV_PATH", "OUTPUT_CHARSET", "LANGUAGE") процесс login при попытке вывести локализованную строку-приветствие загрузит указанную библиотеку и выполнит в ней код с правами root. В доказательство концепции исследователь создал библиотеку, которая после загрузки создаёт копию оболочки "/bin/sh" с установленными битами SUID/SGID, что даёт немедленный доступ к привилегиям суперпользователя.

На данный момент обсуждаемым уязвимостям ещё не присвоены идентификаторы CVE. Ведущие эксперты, включая первоначального автора исправлений для OpenBSD telnetd, Александра Пескова (Solar Designer), сходятся во мнении, что единственным надёжным решением является полный отказ от стратегии чёрного списка в пользу белого. Это подразумевает создание telnetd абсолютно нового, чистого окружения для процесса "/bin/login", куда будут включены только заранее определённые и безопасные переменные, такие как "TERM", "DISPLAY", "USER", "LOGNAME" и "POSIXLY_CORRECT". Именно такой подход, по аналогии с опцией "AcceptEnv" в OpenSSH, был предложен разработчиком Саймоном Йозефссоном и уже реализован в некоторых системах. Например, в дистрибутиве Rocky Linux 9 используется модифицированная версия telnetd с проверкой по белому списку, которая не подвержена данным уязвимостям. Аналогичная защита присутствует в реализации telnetd для FreeBSD. Примечательно, что OpenBSD полностью удалил telnetd из базовой системы ещё в 2005 году, что в свете новых открытий выглядит дальновидным решением.

Уязвимости подтверждены в пакете GNU Inetutils, сервер telnetd из которого по умолчанию входит в такие популярные дистрибутивы, как Debian, Ubuntu и их производные. На момент публикации официальные исправления от разработчиков Inetutils отсутствуют. Это создаёт серьёзные операционные риски для организаций, где подобное программное обеспечение может быть развёрнуто. В качестве временных мер защиты специалистам по кибербезопасности настоятельно рекомендуется полностью отключить и удалить сервис telnetd, если его использование не является критически важным. В случаях, когда отключение невозможно, следует рассмотреть возможность замены стандартной реализации на версию с проверкой по белому списку, подобную той, что используется в Rocky Linux, или перейти на использование более безопасных протоколов, таких как SSH (Secure Shell). Администраторам также необходимо проводить регулярный аудит систем на наличие неиспользуемых сетевых служб и следить за обновлениями от вендоров. Данный инцидент служит суровым напоминанием о том, что устаревшие протоколы и неполные исправления могут создавать угрозы на протяжении десятилетий, требуя от специалистов постоянной бдительности и глубокого понимания архитектуры систем.

Детали уязвимости

Ссылки