Tailscale опубликовала апдейт расследования по уязвимостям в Tailscale SSH. Большинство найденных проблем связаны с повышением привилегий: пользователь, уже имеющий право подключаться по Tailscale SSH, в некоторых обстоятельствах мог выполнять действия за пределами прав своего настроенного локального пользователя, вплоть до получения повышенных привилегий. Исправления для большинства проблем уже внедрены, инженеры завершают тестирование перед выпуском пропатченного клиента.
Пока обновление готовится, клиентам предложен набор временных мер. Полный масштаб находок и список затронутых конфигураций ещё проверялся, поэтому конкретные версии и условия эксплуатации в апдейте не названы.
Что именно изменилось
Новых значений по умолчанию апдейт не вводит — это набор рекомендаций. Главная из них — отключить SSH-форвардинг, если он не нужен: задать переменную окружения TS_SSH_DISABLE_FORWARDING=1 в окружении службы tailscaled и перезапустить службу. Это отключает форвардинг, не отключая Tailscale SSH целиком, и, по формулировке апдейта, снижает риск нескольких наиболее серьёзных находок.
Дополнительно рекомендуется пересмотреть политики доступа Tailscale SSH, чтобы подключались только те пользователи и устройства, которым доступ действительно нужен, временно ужесточить доступ к чувствительным системам и установить пропатченный релиз клиента, когда он появится. Отключать Tailscale SSH всем не рекомендуется: «we're not recommending that everyone disable Tailscale SSH».
Пропатченный клиент инженеры целят выпустить к концу вторника 27 октября при условии успешного завершения тестирования. После релиза обещан security advisoryофициальное уведомление о безопасности с перечнем подтверждённых уязвимостей, затронутых версий и конфигураций, их влиянием и способами устранения с подтверждёнными уязвимостями, затронутыми версиями и конфигурациями, их влиянием и способами устранения, а затем технический блог-пост о находках, первопричинах и инженерных изменениях.
Как форвардинг устроен в коде
Форвардинг (пересылка) — это перенаправление сетевого трафика через SSH-соединение: клиент просит сервер открыть соединение к другому адресу или порту и пропустить трафик через уже установленный SSH-канал. Локальная пересылка (ssh -L) направляет трафик с машины клиента к цели, доступной серверу; обратная (ssh -R) — наоборот, от сервера к цели, доступной клиенту. Пересылать можно как TCP-порты, так и Unix-сокеты. В Tailscale SSH решение о каждой такой пересылке принимают обработчики, которые сервер вызывает при поступлении запроса: отдельные для локальной пересылки TCP-портов, локальной пересылки на Unix-сокет, обратной пересылки TCP-портов и обратной пересылки на Unix-сокет. Эти обработчики подключаются к серверу при создании соединения.
Каждый обработчик первым делом проверяет глобальный выключатель и политику. Для локального TCP-форвардинга условие такое:
if sshDisableForwarding() || c.finalAction == nil || !c.finalAction.AllowLocalPortForwarding {
return false
}Итоговое действие политики доступа SSH для данного соединения — это структура, поля которой говорят, что соединению разрешено (в частности, разрешена ли локальная или обратная пересылка портов). Пока действие не вычислено, оно пустое, и запрос отклоняется; если в действии не выставлено разрешение на локальную пересылку — тоже. Unix-варианты проверяют те же условия и при отказе возвращают ошибку отклонения. Обратные варианты аналогично смотрят на разрешение обратной пересылки.
Зафиксированный ранее бит форвардинга может устареть, поэтому перед разрешением политика перепроверяется отдельной проверкой. При успехе увеличивается счётчик локальных или обратных форвардов.
Итоговое действие политики вычисляется по политике SSH, которая берётся из netmap — снимка состояния сети, рассылаемого control-сервером клиенту, — либо из отладочного файла с политикой. В результате получаются действие, локальный пользователь, набор переменных окружения и совпавшее правило. Именно из этого действия обработчики берут разрешения на форвардинг.
Предыстория: как Tailscale SSH работал раньше
Tailscale SSH включается командой tailscale set --ssh. При включении Tailscale заявляет порт 22 для своего IP-адреса — только для трафика из tailnet — и направляет SSH-трафик к SSH-серверу, который запускает сам Tailscale, вместо стандартного sshdстандартного SSH-демона операционной системы, обслуживающего входящие SSH-подключения. Файлы /etc/ssh/sshd_config и ~/.ssh/authorized_keys при этом не меняются, поэтому обычные SSH-подключения к тому же хосту вне Tailscale продолжают работать.
Аутентификация и шифрование идут по WireGuardпротоколу VPN, который шифрует и аутентифицирует трафик между узлами сети с использованием node keys — ключей узла, которыми Tailscale уже обменялся между участниками сети. Поэтому SSH-сервер Tailscale заранее знает, кто именно к нему подключается, и не требует от клиента дополнительных доказательств: используется тип аутентификации none, и он безопасен именно потому, что подлинность стороны уже установлена на уровне сети, а не самого SSH-протокола. Управление доступом централизовано: чтобы отозвать у пользователя доступ, обновляют access control policyправила доступа, которые задают, каким пользователям и устройствам разрешено подключаться, и клиенты реагируют на новые правила за секунды — это останавливает уже установленные SSH-соединения. Опционально check modeрежим, в котором перед подключением требуется заново войти в систему требует повторной аутентификации у identity providerвнешнего поставщика входа, через которого пользователь подтверждает свою личность перед подключением; после этого повторная аутентификация не нужна в течение 12 часов или заданного периода проверки.
Ограничения были заявлены заранее: подключаться можно только к Linux-устройствам и к macOS с открытым вариантом tailscale + tailscaled CLI, клиентом может быть любое устройство с Tailscale; на Synology и QNAP Tailscale SSH работать не может; порт фиксирован — предполагается 22, настроить другой нельзя.
Почему это сделали
В апдейте причина описана через характер находок: большинство проблем — повышение привилегий, то есть авторизованный пользователь мог выйти за пределы прав своего локального пользователя. В обсуждении на Lobsters суть уточняется: пользователь, уже имеющий право подключаться по SSH к узлу, мог обращаться к сокетам на узле или перенаправлять их, хотя они должны быть доступны только root. Там же наиболее релевантным назван бюллетень TS-2026-014идентификатор бюллетеня безопасности Tailscale, названный в обсуждении наиболее релевантным этому инциденту.
Форвардинг оказался в центре временных мер потому, что его отключение прямо названо снижающим риск нескольких наиболее серьёзных находок. Механика это объясняет: все обработчики пересылки начинают с проверки глобального выключателя, поэтому одна переменная окружения закрывает целый класс операций, не трогая остальной Tailscale SSH.
Что это меняет на практике
Для тех, кто пользуется форвардингом, временная мера означает его отключение до установки патча — с перезапуском tailscaled, который, как указано в документации, останавливает существующие сессии Tailscale SSH. Кому форвардинг не нужен, перезапуск всё равно потребуется, чтобы переменная подхватилась.
Отключить Tailscale SSH целиком можно командой tailscale set --ssh=false на устройстве, но перед этим нужно убедиться, что есть другой способ подключиться, иначе можно потерять доступ к устройству. Выполнение tailscale set --ssh приводит к зависанию существующих SSH-соединений к Tailscale IP хоста.
Сведений о том, какие именно существующие конфигурации перестанут работать после патча, в апдейте нет — их обещают перечислить в security advisory. Пока единственная определённая рекомендация — применить пропатченный релиз, когда он станет доступен.
Ограничения и открытые вопросы
Документация признаёт, что Tailscale SSH подходит не для всех сценариев. Среди неподходящих случаев — многопользовательские машины, где у разных OS-пользователей разные права SSH в политиках доступа; машины с исходящим доступом Tailscale SSH, код на которых не вызывает доверия; машины, где через authorized_keys ограничивают команды удалённых пользователей. Подключиться к серверу Tailscale SSH по не-Tailscale IP-адресу нельзя.
Часть параметров поведения задаётся окружением и имеет значения по умолчанию. Время на завершение аутентификации — 120 секунд, переопределяется переменной TS_SSH_LOGIN_GRACE_TIME; недопустимое значение использует значение по умолчанию. Таймаут простоя по умолчанию равен 0, что означает его отсутствие, и задаётся переменной TS_SSH_IDLE_TIMEOUT. Очередь ожидающих сессий ограничена 16, при переполнении сессия отклоняется. Таймауты разбираются так, что принимается либо голое число секунд, либо Go-длительность вида 90s.
Открытыми остаются два документа, которые ещё не опубликованы: security advisory с подтверждёнными уязвимостями, затронутыми версиями и конфигурациями, их влиянием и способами устранения, и технический блог-пост о находках, первопричинах и инженерных изменениях. До их выхода полный масштаб проблем и точный перечень затронутых конфигураций остаются неопределёнными.
