ИИтог

Tailscale закрыла уязвимость: root-доступ по SSH в обход ACL

безопасностьРедакция ИИтогHacker News🔥64Рейтинг ИИтог · значимость 54 · 76 баллов · 19/ч · 33 коммент.
Tailscale закрыла уязвимость: root-доступ по SSH в обход ACL

Tailscale, сервис приватных VPN-сетей поверх WireGuard, опубликовал бюллетень безопасности TS-2026-009, об уязвимости в компоненте Tailscale SSH. Проблема была в том, как сервис обрабатывал имена пользователей, начинающиеся с символа дефис. На узлах с Linux такие имена передавались напрямую в системную утилиту getent как аргумент командной строки, а ведущий дефис такая утилита воспринимает не как часть текста, а как флаг.

Конкретный пример из бюллетеня: пользователь, подключившийся по SSH под именем «-i», заставлял getent воспринять эту строку как флаг «--no-idn», и утилита выводила содержимое всего файла учётных записей, начиная с самой первой строки, записи root. Tailscale SSH принимал этот вывод за найденную учётную запись и открывал для подключившегося интерактивную root-сессию. Так происходило, даже если правила контроля доступа (ACL) в сети Tailscale прямо запрещали обычным пользователям заходить под root: уязвимость обходила именно правило autogroup:nonroot, которое создано для этого запрета.

Под угрозой были пользователи Tailscale SSH на Linux-узлах, чья защита от root-доступа опиралась на ограничение autogroup:nonroot. Для атаки требовался уже разрешённый SSH-доступ к узлу: уязвимость работала как способ повысить права внутри уже открытого подключения, а не как способ проникнуть на узел снаружи. Tailscale исправила проблему в версии 1.98.9: теперь сервис отклоняет имена пользователей с ведущим дефисом ещё до того, как передать их в getent.

В том же бюллетене Tailscale закрыла ещё одну уязвимость, TS-2026-008, из класса отказа в обслуживании. Функции Tailscale Serve и Tailscale Funnel перенаправляют входящие HTTP-запросы на локальные сервисы, сопоставляя путь запроса с настроенными точками подключения; чтобы найти нужную точку, сервис поднимался вверх по пути запроса по одному каталогу за раз, ожидая дойти до корня «/». Если путь запроса не начинался с «/», этот подъём никогда не доходил до корня и не находил точку подключения, цикл зависал навсегда. Тайм-аут для запроса предусмотрен не был, поэтому один такой запрос надолго занимал одно ядро процессора, на всё время работы сервера.

Для Tailscale Serve вредоносный запрос мог отправить любой участник той же приватной сети Tailscale (в терминологии сервиса, tailnet), у которого был доступ к узлу. Для Tailscale Funnel, который открывает узел для запросов из интернета, отправить такой запрос мог вообще любой посторонний хост без какой-либо авторизации. Обе уязвимости исправлены в версии 1.98.9, и Tailscale рекомендует всем, кто использует SSH, Serve или Funnel, обновиться до этой версии или новее. Об уязвимостях сообщили специалисты Anthropic и Ada Logics.

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

  • Tailscale опубликовала бюллетень безопасности TS-2026-009: до версии 1.98.9 SSH-логин с ведущим дефисом (например, «-i») позволял получить root-сессию в обход правила autogroup:nonroot в ACL на Linux-узлах.
  • Причина, утилита getent получала имя пользователя как аргумент командной строки и принимала «-i» за флаг «--no-idn», из-за чего выводила содержимое всего файла учётных записей начиная с root.
  • В том же выпуске закрыта TS-2026-008: некорректный HTTP-запрос к узлу с включённым Tailscale Serve или Funnel мог намертво занять одно ядро процессора из-за бесконечного цикла разбора пути без тайм-аута.
  • Tailscale Funnel открыт всему интернету без авторизации, поэтому атаку на отказ в обслуживании (TS-2026-008) мог провести любой посторонний хост, а не только участник сети Tailscale.
  • Обе уязвимости исправлены в Tailscale версии 1.98.9; о них сообщили специалисты Anthropic и Ada Logics.

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

Tailscale, популярный сервис приватных VPN-сетей поверх WireGuard, которым пользуются разработчики и IT-команды для удалённого доступа к серверам. Бюллетень TS-2026-009 описывает нетипичный класс уязвимости: имя пользователя, которое сервис просто передавал во внешнюю системную утилиту, само превращалось в опасный флаг командной строки и раскрывало данные о root. Показательно, что обе уязвимости, TS-2026-008 и TS-2026-009, нашли и передали Tailscale специалисты компании Anthropic (разработчика моделей Claude) совместно с Ada Logics: здесь Anthropic выступает не как ИИ-компания, а как исследователь безопасности.

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

В первую очередь, администраторам и пользователям Tailscale SSH на Linux-узлах, чья защита от root-доступа держалась на правиле autogroup:nonroot. Во вторую, всем, кто включил Tailscale Funnel: эта функция открывает узел для запросов из интернета без авторизации, поэтому DoS-уязвимость TS-2026-008 касалась не только участников сети, но и любого постороннего в интернете. Пользователей Tailscale Serve, доступного только участникам приватной сети, риск тоже касался, хотя и в более узком кругу.

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

Практический шаг один: обновить Tailscale до версии 1.98.9 или новее на всех узлах, где используются SSH, Serve или Funnel. Администраторам, которые полагаются на ограничение autogroup:nonroot для запрета root-доступа обычным пользователям, стоит после обновления перепроверить, что правило действительно соблюдается. Тем, у кого включён Funnel и узел смотрит в интернет, обновление стоит сделать в первую очередь, там атаковать мог кто угодно без авторизации.

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

Да: это официальный бюллетень безопасности Tailscale с собственной нумерацией уязвимостей TS-2026-xxx, источник первичный и авторитетный. В тексте указаны точные технические детали: конкретное имя пользователя «-i», конкретный флаг «--no-idn», конкретная версия исправления 1.98.9, и названы исследователи, сообщившие об уязвимостях: Anthropic и Ada Logics. Это стандартная процедура ответственного раскрытия уязвимостей, а не утечка или домысел.

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

Главный риск для тех, кто не обновится, эскалация прав: пользователь с обычным SSH-доступом мог получить root одним лишь выбором имени при подключении, без эксплойтов и специальных инструментов. Второй риск, отказ в обслуживании через Funnel, где для атаки не требовалось вообще никакой авторизации: один вредоносный HTTP-запрос занимал ядро процессора навсегда. Обе проблемы возникли не из-за ошибки в криптографии, а из-за доверия к пользовательскому вводу, который передавался дальше без проверки, характерное и легко повторимое место для похожих ошибок в другом программном обеспечении, если разработчики не учтут этот случай.