TS-2026-009: Tailscale SSH 中的不安全参数处理导致允许获取 root 权限

# 安全公告 · Tailscale 来源：https://tailscale.com/security-bulletins ### TS-2026-008 (https://tailscale.com/security-bulletins#ts-2026-008) ***描述***：向运行 Tailscale Serve 或 Funnel 的节点发送一个格式错误的 HTTP 请求，会导致 CPU 核心永久性地被占满，造成拒绝服务。 #### 发生了什么？ Tailscale Serve (https://tailscale.com/docs/features/tailscale-serve) 和 Tailscale Funnel (https://tailscale.com/docs/features/tailscale-funnel) 通过将请求路径与已配置的挂载点进行匹配，将入站 HTTP 请求代理到本地后端。在解析请求的处理程序时，Tailscale 会沿着请求路径逐级向上遍历目录，期望最终能到达根路径 `/`。对于路径不是以 `/` 开头的请求，此遍历永远不会到达 `/`，也永远不会匹配到挂载点，导致循环无限执行。由于服务器未设置请求超时，没有任何机制能中断该循环，该 goroutine 会永久占用一个核心 100% 的资源。现在 Tailscale 在遇到非绝对路径时会终止路径遍历，返回空处理程序并关闭请求。此漏洞已在 Tailscale 1.98.9 及更高版本中修复。 #### 造成的影响是什么？ 攻击者可以发送精心构造的 HTTP 请求，永久消耗目标节点上的一个 CPU 核心。对于 Tailscale Serve，该请求可以来自对目标节点具有访问权限的 tailnet 内的任何对等节点。对于 Tailscale Funnel，该请求可以来自互联网上的任何未经认证的主机。 #### 谁受到了影响？ 运行 Tailscale Serve 或 Tailscale Funnel 且版本低于 1.98.9 的节点。 #### 我需要做什么？ 如果你运行 Tailscale Serve 或 Tailscale Funnel，请升级到 Tailscale 1.98.9 或更高版本。 #### 致谢 感谢 Anthropic 和 Ada Logics 报告此问题。 ### TS-2026-009 (https://tailscale.com/security-bulletins#ts-2026-009) ***描述***：Tailscale SSH 对命令行参数处理不安全，允许 `root` 用户访问，违反了 ACL 策略。 #### 发生了什么？ Tailscale SSH (https://tailscale.com/docs/features/tailscale-ssh) 之前接受以 `-` 字符开头的用户名。在 Linux 平台上，这些用户名会被作为参数传递给 `getent(1)` 以检索对应的 `passwd` 条目，在这里它们被解释为允许攻击者控制行为的标志。具体来说，如果用户使用用户名 `-i` 连接，这会被解释为 `--no-idn`，并且 `getent` 会从 `root` 用户开始打印整个 `passwd` 文件内容，导致 Tailscale 打开一个交互式的 `root` 会话。现在 Tailscale SSH 拒绝以破折号开头的用户名。此漏洞已在 Tailscale 1.98.9 及更高版本中修复。 #### 造成的影响是什么？ 对 Linux 节点具有 SSH 访问权限的用户可以通过使用用户名 `-i` 连接来获得 `root` 会话，这违反了 ACL 策略。 #### 谁受到了影响？ 使用 Tailscale ACL 中的 `autogroup:nonroot` 用户限制的 Linux 主机上的 Tailscale SSH 用户。 #### 我需要做什么？ 如果你使用 Tailscale SSH，请升级到 Tailscale 1.98.9 或更高版本。 #### 致谢 感谢 Anthropic 和 Ada Logics 报告此问题。 ### TS-2026-007 (https://tailscale.com/security-bulletins#ts-2026-007) ***描述***：Services 中的入站数据包过滤不足，允许访问绑定到回环接口的监听器。 #### 发生了什么？ Tailscale Services (https://tailscale.com/docs/features/tailscale-services) 是虚拟的 tailnet 目标，可以由你的 tailnet 中的一个或多个节点托管。它们允许你将数据库等网络资源与支持它们的节点分开管理。在早于 1.98.9 的 Tailscale 版本中，宣告服务的节点可以接受发往其未宣告端口的服务 IP 的入站流量。在这种情况下，Tailscale 会将这些数据包转发到主机上监听同一端口的任何回环接口进程，从而使它们可以被远程访问。现在 Tailscale 会过滤这些数据包，并在没有对应服务端口处理程序时发送适当的 TCP RST 响应进行拒绝。此漏洞已在 Tailscale 1.98.9 及更高版本中修复。 #### 造成的影响是什么？ 拥有 Tailscale Service ACL 授权的用户可以针对其未宣告的端口进行连接，并到达托管该服务的节点上监听回环接口的进程。 #### 谁受到了影响？ 依赖于节点上仅回环网络访问限制来托管服务的 Tailscale Services 用户。 #### 我需要做什么？ 如果你在节点上托管 Tailscale Services，并且这些节点上存在绑定到回环接口的进程，请升级到 Tailscale 1.98.9 或更高版本。 ### TS-2026-006 (https://tailscale.com/security-bulletins#ts-2026-006) ***描述***：Tailscale SSH 允许用户通过数字 UID 进行寻址，绕过了 ACL 中 `root` 用户的限制。 #### 发生了什么？ Tailscale SSH (https://tailscale.com/docs/features/tailscale-ssh) 之前允许用户通过其用户名 *或* UID 值进行寻址，但是 ACL 强制执行中的 `root` 用户限制只考虑了前者。拥有非 `root` SSH 访问权限的用户如果使用 `0@host` 进行寻址，将能够违反 ACL 策略访问 `root`。现在 Tailscale 通过 SSH 禁止使用 UID 或纯数字用户名以避免歧义。此漏洞已在 Tailscale 1.98.9 及更高版本中修复。 #### 造成的影响是什么？ 对节点具有 SSH 访问权限的用户可以使用用户名 `0` 作为 `root` 进行 SSH 连接，这违反了 ACL 策略。 #### 谁受到了影响？ 在 Linux/Unix 主机上使用 Tailscale ACL 中的 `autogroup:nonroot` 用户限制的 Tailscale SSH 用户。 #### 我需要做什么？ 如果你使用 Tailscale SSH，请升级到 Tailscale 1.98.9 或更高版本。 #### 致谢 感谢 Tim Hoffman (GM) 报告此问题。 ### TS-2026-005 (https://tailscale.com/security-bulletins#ts-2026-005) ***描述***：Tailscale Serve Unix 套接字代理目标未限制为 `root`，允许非 root 操作员代理特权套接字。 #### 发生了什么？ Tailscale Serve (https://tailscale.com/docs/features/tailscale-serve) 可以将入站连接代理到本地后端，包括配置为 `proxy` 目标的 Unix 域套接字（例如 `proxy: unix:/var/run/docker.sock`）。被配置为 Tailscale 操作员 (https://tailscale.com/docs/reference/tailscale-cli) 的非 root 本地用户可以通过 LocalAPI 写入 Serve 配置。Tailscale 限制只有 root 用户才能将文件系统路径指定为 Serve 目标，以防止权限提升，但是此检查未涵盖 Unix 套接字代理目标。因此，非 root 操作员可以让以 root 身份运行的 `tailscaled` 进程代理到特权 Unix 套接字，从而绕过本应阻止其访问的文件系统权限。现在 Tailscale 将 Unix 套接字代理目标限制为 `root` 用户，与已应用于文件系统处理程序的要求保持一致。此漏洞已在 Tailscale 1.98.9 及更高版本中修复。 #### 造成的影响是什么？ 被配置为 Tailscale 操作员的非 root 用户可能导致以 `root` 身份运行的 `tailscaled` 进程连接到其本来无法访问的特权 Unix 套接字。 #### 谁受到了影响？ Linux/Unix 主机上运行 Tailscale Serve，并且非 root 本地用户被配置为 Tailscale 操作员，同时存在特权 Unix 套接字（例如 Docker、containerd 或 CRI 套接字）的情况。 #### 我需要做什么？ 如果你使用 Tailscale Serve，请升级到 Tailscale 1.98.9 或更高版本。 #### 致谢 感谢 Tim Sageser (dtrsecurity (https://dtrsecurity.com/)) 报告此问题。 ### TS-2026-004 (https://tailscale.com/security-bulletins#ts-2026-004) ***描述***：Tailscale SSH Unix 套接字转发未遵循符号链接权限，导致可以访问特权套接字。 #### 发生了什么？ Tailscale SSH (https://tailscale.com/docs/features/tailscale-ssh) 支持在客户端与主机之间转发 TCP 和 Unix 套接字。Tailscale SSH 的 Unix 套接字转发中的文件系统权限检查存在一个缺陷，允许非特权用户在远程主机上绑定并访问特权套接字。之前，当 Tailscale SSH 评估请求的套接字的文件系统权限时，它只执行请求路径相对于其允许列表和禁止列表的词法匹配。攻击者在他们拥有的路径（例如 `/home/$USER/my.sock`）上创建一个指向受保护资源（例如 `/var/run/docker.sock`）的符号链接，就可以在 SSH 连接中绑定并访问后者的路径。这是可能的，因为 Tailscale 以 `root` 身份运行，因此可以访问特权目标。除了词法匹配之外，Tailscale SSH 现在会检查请求的和配置的路径是否存在符号链接，并对其求值以确保其目标也在授权范围内。目标在已配置的允许列表之外的符号链接将被拒绝。此漏洞已在 Tailscale 1.98.9 及更高版本中修复。 #### 造成的影响是什么？ 非特权用户本可以访问远程主机上的特权 Unix 套接字。 #### 谁受到了影响？ 在共享 Linux/Unix 主机上使用 Tailscale SSH 并且依赖文件系统权限来限制对 Unix 套接字访问的用户。 #### 我需要做什么？ 如果你使用 Tailscale SSH，请升级到 Tailscale 1.98.9 或更高版本。 #### 致谢 感谢 Tim Sageser (dtrsecurity (https://dtrsecurity.com/)) 报告此问题。 ### TS-2026-003 (https://tailscale.com/security-bulletins#ts-2026-003) ***描述***：OAuth 访问令牌被记录在 tailnet 审计日志中。 #### 发生了什么？ Tailscale 协调服务器会发出审计日志 (https://tailscale.com/docs/features/logging/audit-logging)，记录 tailnet 配置的所有更改，包括访问凭据的创建和管理。Tailscale 协调服务器中的一个错误导致其在描述 OAuth 客户端访问令牌 (https://tailscale.com/docs/features/oauth-clients) 创建的审计日志条目中记录了完整的访问令牌。这使得拥有日志访问权限的其他 tailnet 角色可以获取这些 OAuth 访问令牌。 #### 造成的影响是什么？ 拥有审计日志访问权限的 tailnet 管理员可以从日志中检索 OAuth 访问令牌，并在令牌的一小时有效期内使用它们向 Tailscale API 发出授权请求。 #### 谁受到了影响？ 在 2026 年 3 月 1 日到 2026 年 5 月 29 日期间使用 OAuth 客户端创建访问令牌的所有 tailnet 都受到影响。 #### 我需要做什么？ 客户无需采取任何操作。新的访问令牌现在会以脱敏形式记录在审计日志中。访问令牌的最长有效期为 1 小时，因此所有历史令牌已经过期。 #### 致谢 感谢 Conor Power (Snapchat) 报告此问题。 ### TS-2026-002 (https://tailscale.com/security-bulletins#ts-2026-002) ***描述***：Tailscale 客户端 Web 界面中的 ACL 能力绕过 #### 发生了什么？ Tailscale 客户端运行一个本地 Web 界面 (https://tailscale.com/docs/features/client/device-web-interface) 来管理其设置。此 Web 界面可以选择性地开放给其他 tailnet 对等节点，例如用于管理无头主机上的标记节点（没有 SSH 访问权限）。默认情况下界面是只读的，但 tailnet 管理员可以通过 ACL 授予更改某些设置的权限。Web 界面上的 `/api/routes` 端点允许更改活动的出口节点 (https://tailscale.com/docs/features/exit-nodes) 和已宣告的子网路由 (https://tailscale.com/docs/features/subnet-routers)。这些设置分别受限于 `exitNodes` 和 `subnets` 授权。处理程序中存在一个错误：如果请求体为空，它会将这两个设置重置为空状态，即使调用者没有任何允许这样做的授权。此漏洞已在 Tailscale 1.98.0 及更高版本中修复。 #### 造成的影响是什么？ 恶意 tailnet 节点可以禁用其他运行 Web 界面的 tailnet 节点上的出口节点并清除其已宣告的子网路由。恶意用户需要通过登录检查，并通过 tailnet ACL 被授予对目标节点 `5252` 端口的访问权限。 #### 谁受到了影响？ 运行 Tailscale 版本介于 1.56.0 和 1.98.0 之间，并且明确启用了 Web 界面的 Linux、macOS 和 Windows 节点。 #### 我需要做什么？ 如果你正在使用 Web 界面管理远程节点，请将这些节点升级到 1.98.0 或更高版本。 #### 致谢 感谢 N0zoM1z0 (https://github.com/N0zoM1z0) 报告此问题。 ### TS-2026-001 (https://tailscale.com/security-bulletins#ts-2026-001) ***描述***：tssentineld 中的任意命令执行（拥有提升的权限） #### 发生了什么？ `tssentineld` 是一个 launchd 服务，在 macOS 上存在AlwaysOn.Enabled (https://tailscale.com/kb/1315/mdm-keys#set-tailscale-to-always-be-connected) MDM 策略的受管理环境 (https://tailscale.com/kb/1362/mdm) 中被安装。它的唯一职责是确保 Tailscale.app 在被终止时重新启动。作为 launchd 服务，它以 `root` 身份运行。实现中使用了 NSTask 和 `/bin/sh -c sudo -u [username]`，对用户名使用了基本的字符串模板替换。攻击者如果能够直接访问保存用户名字符串的内存，或者将当前用户名设置为恶意值，就可以利用这一点注入命令，并以与 `tssentineld` 相同的权限运行。此漏洞已在 Tailscale 1.94.0 及更高版本中修复。 #### 造成的影响是什么？ 能够操纵自己的用户名或操纵 tssentineld 内存的恶意本地用户可以以 root 身份执行任意命令。 #### 谁受到了影响？ 从 1.84.0 到 1.92.3 的 macOS 独立版本 (https://tailscale.com/kb/1065/macos-variants)，当通过 MDM 配置启用AlwaysOn.Enabled (https://tailscale.com/kb/1315/mdm-keys#set-tailscale-to-always-be-connected) 策略时受到影响。`tssentineld` 仅在被 MDM 管理并采用AlwaysOn.Enabled (https://tailscale.com/kb/1315/mdm-keys#set-tailscale-to-always-be-connected) 策略的客户端上激活，并且需要管理员权限进行安装和激活。通过内存操作注入恶意命令需要单独的漏洞或现有的 root 访问权限。但是，用户可以通过修改其用户名的方式，让 `tssentineld` 能够以提升的权限执行任意 shell 命令。可从 App Store 获得的 macOS 软件包 (https://tailscale.com/kb/1065/macos-variants) 不支持安装 launchd 守护进程，因此不受影响。 #### 我需要做什么？ 如果你对独立的 macOS 客户端使用AlwaysOn.Enabled (https://tailscale.com/kb/1315/mdm-keys#set-tailscale-to-always-be-connected) 策略，请升级到 1.94.0 或更高版本。 ### TS-2025-008 (https://tailscale.com/security-bulletins#ts-2025-008) ***描述***：没有指定 `--statedir` 或 `TS_STATE_DIR` 的节点，在启用了 Tailnet Lock 的 tailnet 中未能强制执行签名检查。 #### 发生了什么？ 在启用了 Tailnet Lock (https://tailscale.com/kb/1226/tailnet-lock) 的 tailnet 中，运行 `tailscaled` 守护进程（例如在 Linux 上）且未指定 `--statedir` 或 `--state` 的未签名节点未能强制执行所需的签名检查。这使得它们能够与其他同样配置错误的未签名节点通信，或者与加入 tailnet 的恶意节点通信。此行为绕过了针对特定子集节点的 Tailnet Lock 安全策略。