Tailscale SSH 安全漏洞 TS-2026-009

Tailscale 已修复一个关键的安全漏洞，标识为 TS-2026-009，该漏洞允许具有现有 Tailscale ACL 权限的用户在目标主机上将权限提升至 root。该缺陷源于 Tailscale SSH 在与系统实用程序交互时处理用户名的方式，具体表现为允许以连字符开头的用户名被解释为命令行参数。

Root Cause: 不安全参数处理

该漏洞的发生是因为 Tailscale SSH 将用户名直接作为参数传递给 getent(1) 命令以检索密码条目。由于输入未经过适当的清理或分隔，用户可以提供一个以连字符开头的用户名（例如 -i），getent 会将其解释为标志（flag）而非字面意义上的用户名。

这种行为使得通过 Tailscale ACLs 拥有有效 SSH 访问权限的攻击者能够绕过预期的用户限制并获得 root 登录权限。这是一个典型的参数注入漏洞示例，其中用户提供的数据被底层系统调用误认为是控制指令。

Remediation and Fixes: 修复与补救措施

Tailscale 已实施了多项限制以防止此类参数注入：

• 拒绝以连字符开头的用户名： Tailscale SSH 现在会明确拒绝任何以连字符开头的用户名。
• 限制数字用户名： 为了避免歧义并防止进一步的潜在利用，Tailscale 现在不允许通过 SSH 使用 UID 或仅包含数字的用户名。

Technical Community Analysis: 技术社区分析

TS-2026-009 的披露引发了安全专业人员关于系统调用最佳实践以及替换既有工具风险的广泛讨论。

Argument Handling Best Practices: 参数处理最佳实践

技术批评者指出，调用像 getent 这样的子进程比使用原生 API 或系统调用风险更高。正如用户 @jcarrano 所言：

usernames were passed as arguments to getent(1) to retrieve the corresponding passwd entry Always try to use actual API/system calls (in this case getpwnam) instead of calling sub-processes.

此外，一些开发者认为，修复方案——拒绝带有连字符的用户名——是一种权宜之计，而非结构性修复。一种更稳健的方法应该是使用 -- 分隔符，该分隔符标志着命令行标志的结束，并确保所有后续参数都被视为位置参数。

Tailscale SSH vs. OpenSSH: Tailscale SSH 对比 OpenSSH

此次事件重新引发了关于使用专有或较新的 SSH 实现与行业标准 OpenSSH 之间的争论。几位社区成员表达了对 OpenSSH 的偏好，原因是其拥有数十年经受过实战检验的安全记录。

tailscale ssh: replacing a 25-year-old battle-tested codebase with a startup's Go rewrite and then acting surprised when it has bugs

一些组织继续仅将 Tailscale 用于其 NAT 穿透和 VPN 功能，同时依靠传统的 OpenSSH 和 SSH 证书进行实际的身份验证和访问管理，以最大限度地减少攻击面。

Summary of Impact: 影响总结

Feature	Vulnerability	Impact	Fix
Tailscale SSH	Argument Injection via getent	Root Access Escalation	Blocked leading dashes and numeric usernames