Tailscale SSH: estar autorizado na rede não deveria significar acesso a root

O Tailscale publicou a versão 1.104.4 para corrigir problemas no servidor SSH integrado e em funcionalidades relacionadas.[2] No encaminhamento de sockets Unix, operações podiam ser executadas pelo processo privilegiado do Tailscale, em vez de respeitar integralmente os privilégios do usuário conectado.[2] Não é um detalhe de interface: é uma quebra na fronteira entre autorização de acesso e autoridade dentro da máquina.

O que muda para quem desenvolve

O ataque descrito exige controle de um dispositivo autorizado pela política a iniciar uma sessão SSH com encaminhamento permitido.[2] Portanto, não se trata de entrada irrestrita pela internet.[2] Mesmo assim, a pesquisadora demonstrou em laboratório acesso ao socket do Docker com consequências de comprometimento de root.[2]

A correção passa a executar o encaminhamento com a identidade do usuário da sessão, sujeito às permissões do sistema operacional.[2] A lição de arquitetura é preservar essa separação em toda integração privilegiada: poder abrir uma sessão não deve conceder implicitamente as capacidades do processo que a transporta.

Para avaliar o impacto, pense também no que uma máquina de desenvolvimento autorizada poderia alcançar. Minha recomendação é revisar relações de acesso entre dispositivos, não apenas a lista de pessoas com conta.

Como aplicar

Comece pelo inventário dos servidores que usam o SSH integrado e pela atualização para 1.104.4 ou posterior, conforme a recomendação apresentada na matéria.[2] Identifique destinos com Docker e outros sockets administrativos e revise permissões amplas entre dispositivos.

Como contenção para servidores ainda não atualizados, a reportagem informa TS_SSH_DISABLE_FORWARDING=1 no ambiente do serviço tailscaled, seguido de reinicialização.[2] Planeje a mudança com acesso alternativo e verifique quais fluxos legítimos dependem do encaminhamento. Não descubra essa dependência depois de perder o acesso administrativo.

Um experimento defensivo pode usar uma máquina isolada e um socket de teste, sem privilégios reais. Defina quais usuários deveriam acessá-lo e confira se a política de rede e as permissões locais produzem exatamente esse resultado após a atualização. O objetivo é validar uma fronteira, não reproduzir comprometimento em produção.

Cuidados e limites

O modo SSH check não elimina o defeito de encaminhamento dentro de uma sessão já aprovada.[2] Login adicional não substitui correção de autorização.

A pesquisadora e o fornecedor divergem sobre chamar o problema de “wormable”: ela observou propagação entre dispositivos permitidos; o Tailscale descreve movimento lateral limitado pelas políticas existentes.[2] Na publicação, não havia indicação de exploração real.[2] Preserve essa distinção ao comunicar o risco.

Se uma chave de dispositivo tiver sido roubada, reinstalar o servidor não a revoga por si só; o relatório citado recomenda excluir o dispositivo no plano de controle.[2] Recuperação precisa tratar credenciais e confiança, além do sistema de arquivos.

Fonte

[2] Fonte: The Hacker News