Tailscale SSH：调查与修复更新

原文 ↗ Hacker News 讨论 ↗

Tailscale 最近披露其 Tailscale SSH 功能中存在权限提升漏洞，这引发了人们对把网络访问和认证都交给一家 VPN 提供商的担忧。评论者指出，这些漏洞主要影响将 SSH 授权委托给 Tailscale、而不是使用标准 OpenSSH 的部署，并讨论了几乎立即公开披露、从而几乎没给公司多少提前警告的做法是否合适。此次事件也再次引发了人们对 Tailscale 日益扩大的功能集和攻击面的担忧，促使一些人更倾向于更简单的基于 WireGuard 的方案，并将 Tailscale 仅视为纵深防御策略中的一层。

Tailscale SSH 功能的状态

  • 多位评论者澄清，Tailscale SSH 并非默认启用；必须显式打开。
  • 它并非在所有平台上都可用。
  • 许多用户表示自己从未使用过它，而是在 tailnet 上运行标准的 OpenSSH。

漏洞的性质与严重性

  • 讨论的主要问题是 Tailscale SSH 中的权限提升：一个已经获得授权的 Tailscale SSH 用户，有时可以获得比其本地账户应有权限更多的权限。
  • 一位前员工/管理员指出，影响仅限于：
    • 启用了 Tailscale SSH（而非普通 SSH）的节点。
    • 允许非 root、非 sudo 账户的 ACL；此时权限提升会破坏最小权限假设。
  • 按当前公开认知，这并不是对所有人的未认证“RCE”，但有几位提到仍在研究可能的未认证攻击路径。
  • 使用 Tailscale SSH 的 Headscale 部署同样受影响，因为漏洞在 tailscaled 中。

披露与沟通

  • 有人批评措辞含糊（“most”、“in some circumstances”）是在打太极，并担心这掩盖了更严重的漏洞。
  • 也有人认为这种语言是在调查过程中保持谨慎。
  • 给予 Tailscale 的简短预发布通知窗口被普遍认为值得质疑。

复杂性、攻击面与产品方向

  • 一些评论者认为 Tailscale 的功能已经变得臃肿（SSH、Taildrop、Taildrive、Funnel 等），扩大了攻击面。
  • 有人担心基本问题（例如输入校验）不断出现，而深度代码审计似乎是临时性的。
  • 一些组织表示，由于感知到的风险，他们已经从 Tailscale 迁走。
  • 还有人指出，你可以重新编译去掉许多功能的 tailscaled，但这并非官方做法，且在支持上比较尴尬。有人请求提供一流的“最小化”构建。

使用模式与替代方案

  • 许多人说他们禁用了 Tailscale SSH，改为在 Tailscale 上使用 OpenSSH，或者只用经典 SSH/OpenVPN/WireGuard 并手动管理密钥。
  • 面向企业的用户强调 Tailscale SSH 的好处（集中式认证、ACL、MFA、审计记录），但也承认这会增加复杂性。
  • 提到的替代方案包括纯 WireGuard、Headscale、NetBird、Nebula、IPsec，以及自建 VPS 中枢方案；它们都在便利性、控制力和更小的功能面之间做权衡。

安全态势与最佳实践

  • 强烈的共识是，Tailscale 应被视为一层防御，而不是唯一的门禁：
    • 服务本身仍应执行自己的认证（HTTPS、应用层认证）。
    • tailnet 暴露应被视为类似互联网暴露。
  • 关于最小权限配置是否会让这个漏洞更严重存在争论（因为权限提升破坏了刻意设定的限制），还是在已经把 root/sudo 交给 Tailscale SSH 的情况下影响较小。
  • 更广泛的主题包括纵深防御、最小化攻击面，以及对“自己实现 SSH 服务器”与坚持使用 OpenSSH 之间的取舍保持怀疑态度。