Tailscale、ソケット転送を悪用してrootアクセスを可能にするSSHの脆弱性を修正

Tailscaleは、組み込みSSHサーバーにおける深刻なセキュリティ欠陥に対処するため、バージョン1.104.4をリリースしました。この欠陥により、攻撃者はターゲットマシン上でrootへの権限昇格を行う可能性があります。Cyberdione Labsのエリカ・ウィンディッシュ氏による報告書で公開されたこれらの脆弱性は、ネットワーク接続の転送処理に影響を与え、公開からわずか数日後にパッチが適用されました。

何が起きたか

核心的な問題は、Tailscale SSHサーバーによるUnixソケット転送の処理にあります。ユーザーがSSHセッションを確立すると、Tailscaleのバックグラウンドプロセスはroot権限で転送操作を実行します。システムはアクセスされるソケットのパスを確認しますが、タイミングの脆弱性により、攻撃者は確認後、接続確立前にパスをすり替えることができました。この競合状態（race condition）により、機密性の高いシステムソケットへのアクセスを制限するための安全策が実質的に回避されました。

実験室でのテストにおいて、ウィンディッシュ氏は、ネットワークポリシーによって許可されたデバイスをすでに制御している攻撃者が、Docker制御ソケットやtailscaledローカルAPIへ接続を転送できることを示しました。これにより、管理者認証情報を必要とせずにrootシェルへのアクセスと、/etc/shadowなどの機密ファイルの読み取りが可能になりました。この攻撃には盗まれたパスワードや鍵は不要であり、Tailscaleネットワーク内の信頼できるデバイスへの足掛かりのみが必要です。

Tailscaleは、これらの欠陥により未認証の攻撃者が任意のサーバーに接続できるわけではないと明確にしました。アクセスは依然としてネットワークのポリシーファイルによって管理されており、攻撃者はすでにアクセスが許可されているマシンにのみ到達できます。しかし、許可されたセッション内に入ると、権限昇格によりroot専用サービスへの横方向移動（lateral movement）が可能になります。同社はこれらの問題を深刻なセキュリティ問題と表現しましたが、このエクスプロイトが自己複製ワームであるという見解は否定し、自律的な拡散ではなく既存のポリシー権限に依存していると指摘しました。

仕組み

この脆弱性は、権限チェックと実行コンテキストの違いを悪用します。以前は、Tailscaleプロセスがソケットパスを検証した後、rootとして転送操作を実行していました。このウィンドウ中にソケットパスをすり替えることで、攻撃者は意図したソケットではなく、特権を持つソケットへ接続するようにシステムを騙すことができました。バージョン1.104.4の修正では、この挙動を変更し、rootとしてではなくログイン中のユーザーとして転送が行われるようになりました。また、内部のパスチェックへの依存から、オペレーティングシステムのネイティブなファイルパーミッションへの依存へと移行しており、こうした競合状態に対してより堅牢です。

この変更は特に、ソケット転送の欠陥を対象としたブレットインTS-2026-014に対応しています。今回のアップデートでは、他の3つの問題も解決されています。Tailscaleプロセスをクラッシュさせる可能性のあるメモリ枯渇バグ（TS-2026-015）、tailscale serve機能におけるUnixソケット経由でのリモートノード制御を許す欠陥（TS-2026-016）、そしてTLS serve設定におけるヘッダー漏洩の問題（TS-2026-017）です。Tailscale SSHサーバーはLinuxおよびオープンソースのmacOSビルドで動作しますが、攻撃元のデバイスはどのプラットフォームでも構いません。

主要な詳細

• 影響を受けるバージョン: 最も古い影響を受けるバージョンは特定されていませんが、バージョン1.104.4に修正が含まれています。
• 前提条件: 攻撃者は、SSH転送が有効になっており、ネットワークポリシーによって信頼されているデバイスをすでに制御している必要があります。
• 影響: 成功した場合、DockerソケットやtailscaledローカルAPIなど、root専用のソケットへのアクセスが許可されます。
• Headscaleユーザー: セルフホスト型のheadscaleコントロールサーバー（バージョン0.29.5）はまだこれらの問題を修正しておらず、ポリシー内でSSH転送を無効にすることはできません。
• 開示: 報告書は事前の調整なしに公開されました。Tailscaleは公開の2時間前にこれを受け取りました。
• CVEなし: 公開時点では、4つのセキュリティブレットインに割り当てられたCVE識別子や深刻度スコアはありません。

なぜ重要なのか

インフラストラクチャアクセスにTailscaleを使用しているエンジニアリングチームにとって、この事件はデバイスアイデンティティモデルに対する暗黙の信頼のリスクを浮き彫りにします。Tailscale SSHはパスワードではなくデバイスアイデンティティを使用するため、転送が有効になっている場合、単一の信頼できるデバイスが侵害されると、重要なシステムへの経路を提供してしまう可能性があります。テストではステップごとに1秒未満という速さでエクスプロイトが横方向に移動できるため、広範な侵害を防ぐには検出と対応が極めて迅速である必要があります。

Tailscaleのコントロールプレーンのオープンソース代替品であるheadscaleのユーザーにとって、この状況は特に困難です。headscaleは現在、ポリシーでSSH転送を無効にする機能がなく、修正版もまだリリースされていないため、このセットアップを使用している管理者は、すべてのSSH許可が潜在的にrootアクセスを付与している可能性があるものとして扱わなければなりません。これは、セキュリティ態勢を評価する際に、マネージドサービスとセルフホスト型代替品の違いを理解することの重要性を強調しています。

あなたができること

• すべてのTailscaleクライアントとサーバーを直ちにバージョン1.104.4以降に更新してください。
• 更新ができない場合は、tailscaledサービスの環境変数にTS_SSH_DISABLE_FORWARDING=1を設定して転送をブロックしてください。
• SSHアクセスルールを見直し、必要なデバイスとユーザーのみが接続する権限を持っていることを確認してください。
• セッション開始前に再認証を要求するために、機密性の高いシステムでSSHチェックモードを有効にしてください。
• headscaleユーザーの場合、SSH許可を厳しく制限し、不正なrootレベルのアクティビティを監視してください。
• 侵害を疑う場合は、デバイスを再イメージングし、コントロールプレーンから削除してください。再イメージングだけではデバイスキーは失効しないためです。