ИИтог

CVE-2026-32746: в telnetd нашли 32-летний баг переполнения памяти без авторизации

безопасностьРедакция ИИтогHacker News🔥44Рейтинг ИИтог44Влияние60Новизна45Релевантность70Неожиданность50Участники15Достоверность80
CVE-2026-32746: в telnetd нашли 32-летний баг переполнения памяти без авторизации

Компания watchtowr Labs опубликовала технический разбор CVE-2026-32746, уязвимости переполнения буфера в демоне telnetd из состава GNU inetutils, которую обнаружила команда DREAM Security Research Team. Баг сидит в обработчике команды LINEMODE SLC (Set Linemode Characters, «настройка управляющих символов построчного режима») и позволяет атакующему без авторизации затереть примерно 400 байт соседних переменных в статической памяти процесса (область BSS). Код без проверки границ массива не менялся с 1994 года, то есть уязвимости почти 32 года; недавно её всё же исправили.

Механика связана с тем, как Telnet-клиент и сервер согласуют параметры соединения: обмен идёт через служебный байт IAC (0xFF, «интерпретировать как команду»). Сервер запрашивает включение LINEMODE, клиент соглашается, после чего сервер присылает список трёхбайтовых триплетов «функция, флаг, значение», описывающих спецсимволы вроде backspace; клиент может прислать в ответ свои триплеты. Сервер сохраняет присланные значения в глобальный массив фиксированного размера без проверки границ, отсюда и переполнение. Разбор кода показывает, что не любой триплет проходит без изменений: если байт функции больше константы NSLC (0x1e), остаток триплета отбрасывается; байт-значение 0xFF при передаче удваивается (0xFF 0xFF), из-за чего один триплет может «растянуться» с 3 байт до 4, 5 или даже 6.

По словам авторов разбора, из-за общего происхождения кода уязвимость унаследовали независимые форки telnetd, и её «радиус поражения» велик и плохо оценим. Watchtowr Labs подтвердила присутствие бага как минимум в самом inetutils-telnetd, Ubuntu, Debian, FreeBSD 13 и порте FreeBSD 15, NetBSD 10.1, Citrix NetScaler, Apple Mac Tahoe, Haiku, TrueNAS Core, uCLinux, libmtev и DragonFlyBSD, а также прямо заявляет, что баг присутствует во всех крупных дистрибутивах Linux.

У находки есть исторический близнец: в 2005 году точно такая же ошибка, отсутствие проверки границ, была найдена на стороне Telnet-клиента, в функции slc_add_reply (CVE-2005-0469), и исправлена тем же по сути патчем с проверкой границ. Спустя двадцать лет ту же проверку добавили и на стороне сервера.

Авторы отдельно подчёркивают, что превратить переполнение в реальную атаку сложнее, чем кажется: данные, которые может отправить атакующий, жёстко ограничены форматом триплетов и проверками в функциях process_slc и change_slc (отбрасывание триплетов с недопустимым байтом функции, особая обработка нулевого байта функции, удвоение байта 0xFF). Материал обрывается прямо на разборе этих ограничений, поэтому итоговый вывод о том, насколько практически эксплуатируем баг, в доступном тексте не приведён. Числового значения CVSS в источнике тоже нет, авторы иронично называют его «CVSS в три квинтиллиона» вместо реальной оценки; нет и данных о том, что уязвимость уже используется атакующими в реальных инцидентах.

Ключевые факты

  • CVE-2026-32746, переполнение буфера в статической памяти (BSS) обработчика SLC-согласования LINEMODE демона telnetd из GNU inetutils; уязвимость обнаружила команда DREAM Security Research Team.
  • Коду без проверки границ около 32 лет: он не менялся с 1994 года и позволяет атакующему без авторизации затереть примерно 400 байт соседних переменных.
  • Из-за общего происхождения кода баг унаследовали как минимум inetutils-telnetd, Ubuntu, Debian, FreeBSD 13/15, NetBSD 10.1, Citrix NetScaler, Apple Mac Tahoe, Haiku, TrueNAS Core, uCLinux, libmtev и DragonFlyBSD; watchtowr Labs заявляет, что баг есть во всех крупных дистрибутивах Linux.
  • У бага есть близнец 2005 года, CVE-2005-0469, та же ошибка без проверки границ, но в функции slc_add_reply на стороне Telnet-клиента; патч устроен так же.
  • Практическую эксплуатацию сдерживают проверки в process_slc и change_slc (ограничение по значению байта функции, особый случай для нулевого байта, удвоение байта 0xFF); статья обрывается перед выводом об итоговой опасности, и данных о реальных атаках в источнике нет.

Почему это важно

Это редкий случай уязвимости, работающей до аутентификации, в коде, который дожил без изменений почти 32 года и разошёлся копированием по десяткам независимых реализаций telnetd. Telnet формально устарел и вытеснен SSH, но, как отмечают авторы разбора, протокол по-прежнему встречается на боевых системах, там, где производитель поддерживает только его или миграция технически невозможна (например, промышленное оборудование на слабых контроллерах). Общее происхождение кода означает, что патч одного проекта не закрывает баг во всех форках автоматически.

Кому это важно

Администраторам и специалистам по безопасности, которые эксплуатируют или сопровождают системы с включённым telnetd, от промышленного оборудования и встраиваемых устройств до перечисленных в разборе Ubuntu, Debian, FreeBSD, NetBSD, Citrix NetScaler, Apple, Haiku, TrueNAS, uCLinux, libmtev и DragonFlyBSD; сопровождающим пакетов GNU inetutils и его форков; исследователям безопасности, которых интересует механика байт-ориентированных переполнений в сетевых протоколах.

Как это применить

В источнике не названы ни номер исправленной версии, ни дата выпуска патча, сказано только, что исправление в inetutils-telnetd уже применено. Для систем с telnetd практический шаг, обновить пакет из своего дистрибутива или форка до версии с этим патчем, сверившись с бюллетенем конкретного вендора. Там, где сам telnetd не убрать (легаси-оборудование), источник подсказывает общий принцип защиты подобных сервисов: ограничить сетевой доступ к порту telnet firewall'ом или VPN и, где возможно, перейти на SSH, тем более что Telnet и без этой уязвимости передаёт логин и пароль открытым текстом.

Можно ли доверять

Материал, технический разбор от watchtowr Labs, известной команды исследователей по наступательной безопасности, с реальными фрагментами кода (process_slc, change_slc) и ссылкой на протокольный стандарт RFC 1184, что делает техническую часть проверяемой. При этом доступный текст статьи обрывается на середине разбора эксплуатации, до итогового вывода авторов о практической опасности бага; числового CVSS-балла источник не приводит (только шутку про «CVSS в три квинтиллиона»); даты патча или подтверждений эксплуатации в реальных атаках в тексте тоже нет.

Риски и подводные камни

Список затронутых систем в источнике сам назван неполным («форков много»), фактический охват может быть шире перечисленного. Несмотря на теоретическую серьёзность повреждения памяти до аутентификации, данные, которые атакующий может протолкнуть в переполняемый массив, жёстко ограничены форматом триплетов и проверками в process_slc и change_slc, это может заметно усложнить превращение бага в рабочий эксплойт с выполнением кода, но именно этот вывод в доступном фрагменте текста не завершён. Делать выводы о реальной опасности до появления полного анализа или PoC, преждевременно.

«В режиме Linemode с включённым редактированием на стороне клиента сетевой трафик сокращается до пары пакетов на команду, а не на пару пакетов на каждый введённый символ. Это полезно в сетях с большими задержками, потому что пользователь видит локальный отклик при наборе команды и сталкивается с сетевой задержкой только после её ввода. Это также снижает расходы в сетях с потарифной оплатой за пакет...»

— RFC 1184