Tailscale исправила SSH-уязвимости с доступом к root-сокетам
Tailscale выпустила версию 1.104.4, закрывающую четыре проблемы безопасности в Tailscale SSH и функции serve. Наиболее серьёзная из них, описанная в бюллетене TS-2026-014, при уже разрешённом SSH-сеансе позволяла обращаться к Unix-сокетам, доступным только root, включая Docker socket и локальный API tailscaled.
Как работала атака через перенаправление сокетов
Tailscale SSH принимает решение о подключении по идентичности устройства и правилам политики сети, а не по паролю или SSH-ключу. Поэтому злоумышленнику требовался контроль над устройством, которому политика уже разрешала доступ к целевому серверу с включённым forwarding.
Проблема возникала при перенаправлении соединения к Unix-сокету. Фоновый процесс tailscaled проверял путь к сокету, однако затем выполнял операцию с правами root. Исследовательница Erica Windisch из Cyberdione Labs показала, что после проверки путь можно подменить и тем самым обойти ограничение.
В лабораторном тесте перенаправление на управляющий сокет Docker дало root-оболочку и доступ к файлу /etc/shadow без административных прав. Tailscale уточняет, что атака не открывает неаутентифицированный доступ к произвольным SSH-серверам: её пределы задаёт уже действующая политика доступа.
Что изменено в версии 1.104.4
В обновлении сервер Tailscale SSH выполняет forwarding от имени вошедшего пользователя, а не root, и опирается на штатные права файловой системы вместо прежней проверки пути. Такой механизм важен и в сценариях, где доступ к управляющим интерфейсам контейнеров демонстрирует, как доступ к управляющим интерфейсам контейнеров может привести к привилегиям на хосте.
Бюллетень TS-2026-015 описывает возможность исчерпать память сервера в разрешённой SSH-сессии и завершить процесс Tailscale, отключив сетевое подключение узла. В TS-2026-016 исправлены доступ к локальному API tailscaled через tailscale serve и связанная подмена сокета. TS-2026-017 закрывает утечку заголовков разрешений между двумя или более mount-точками при TLS serve.
Проверка конфигурации и временная защита
Пользователям Tailscale SSH следует обновить клиенты и серверы до 1.104.4 или более новой версии. Если обновление пока невозможно, Tailscale рекомендует задать в окружении службы tailscaled переменную TS_SSH_DISABLE_FORWARDING=1 и перезапустить службу: это отключает forwarding, но сохраняет Tailscale SSH.
Компания также советует пересмотреть правила SSH-доступа и оставить его только необходимым пользователям и устройствам. Режим SSH check mode требует повторной аутентификации перед началом сессии, но не блокирует эту группу ошибок, поскольку forwarding выполняется уже внутри одобренного подключения.
Для возможной компрометации одной переустановки устройства недостаточно: его ключ остаётся действительным, пока устройство не удалено из control plane. Владельцам headscale нужно учитывать, что версия 0.29.5 не устраняет описанные проблемы, а forwarding предоставляется в каждой принятой SSH-сессии и не отключается политикой. Практический вывод для бизнеса — обновить Tailscale, отключить forwarding до установки патча и проверить, какие доверенные устройства действительно могут открывать SSH-сессии к критичным серверам.