TS-2026-009: Tailscale SSH の不適切な引数処理により root 権限アクセスが可能に

説明: Tailscale Serve または Funnel を実行しているノードへの単一の不正な HTTP リクエストにより、CPU コアを無期限に占有し、サービス拒否を引き起こす可能性がありました。 何が起こったのか？ Tailscale Serve および Tailscale Funnel は、リクエストパスを設定されたマウントポイントと照合することにより、受信した HTTP リクエストをローカルバックエンドにプロキシします。リクエストのハンドラーを解決する際、Tailscale はリクエストパスをディレクトリごとに上位へ辿り、最終的にルートパス / に到達することを期待していました。パスが / で始まらないリクエストの場合、この辿りは / に到達せず、マウントポイントに一致することもなかったため、ループが無限に回転し続けました。サーバーはリクエストタイムアウトを強制しなかったため、何もスピンを中断せず、ゴルーチンはプロセス存続期間中 1 つのコアを 100% 使用し続けました。Tailscale は現在、絶対パスではないパスのパスウォークを終了し、ハンドラーを返さずにリクエストを閉じます。この脆弱性は Tailscale バージョン 1.98.9 以降で修正されています。 影響は何でしたか？ 攻撃者は、細工された HTTP リクエストを送信することで、ターゲットノードの CPU コアを 1 つ永続的に消費することができました。Tailscale Serve の場合、リクエストはノードにアクセスできるテールネット上の任意のピアから発生する可能性がありました。Tailscale Funnel の場合、リクエストはインターネット上の認証されていないホストから発生する可能性がありました。 誰が影響を受けましたか？ 1.98.9 より前のバージョンで Tailscale Serve または Tailscale Funnel を実行していたノード。 何をすべきか？ Tailscale Serve または Tailscale Funnel を実行している場合は、Tailscale バージョン 1.98.9 以降にアップグレードしてください。 謝辞: この問題をご報告いただいた Anthropic および Ada Logics に感謝いたします。 説明: Tailscale SSH における不適切なコマンドライン引数処理により、ACL に違反して root ユーザーアクセスが可能でした。 何が起こったのか？ Tailscale SSH は以前、先頭に - 文字を含むユーザー名を受け入れていました。Linux プラットフォームでは、これらのユーザー名は getent(1) の引数として渡され、対応する passwd エントリを取得するために使用されましたが、そこでフラグとして解釈され、攻撃者が制御できる動作が可能になりました。具体的には、ユーザーが -i というユーザー名で接続した場合、それは --no-idn として解釈され、getent は root ユーザーから始まる passwd ファイル全体を出力し、Tailscale はインタラクティブな root セッションを開くことになりました。Tailscale SSH は現在、先頭にダッシュが付くユーザー名を拒否します。この脆弱性は Tailscale バージョン 1.98.9 以降で修正されています。 影響は何でしたか？ Linux ノードへの SSH アクセス権を持つユーザーは、-i というユーザー名で接続することにより、ACL ポリシーに違反して root セッションを取得できた可能性があります。 誰が影響を受けましたか？ Tailscale ACL の autogroup:nonroot ユーザー制限に依存している Linux ホストで Tailscale SSH を使用しているユーザー。 何をすべきか？ Tailscale SSH を使用している場合は、Tailscale バージョン 1.98.9 以降にアップグレードしてください。 謝辞: この問題をご報告いただいた Anthropic および Ada Logics に感謝いたします。 説明: Services における不十分なインバウンドパケットフィルタリングにより、ループバックバウンドリスナーへのアクセスが可能でした。 何が起こったのか？ Tailscale Services は、テールネット上の 1 つ以上のノードからホストできる仮想テールネット宛先です。これらは、ノード自体とは別にデータベースなどのネットワークリソースを管理できるようにします。Tailscale バージョン 1.98.9 より前のバージョンでは、サービスをアドバタイズするノードは、アドバタイズしていないポートのサービス IP へのインバウンドトラフィックを受け入れることができました。これらのシナリオでは、Tailscale はこれらのパケットをホストのループバックインターフェイス上の同じポートでリッスンしている任意のプロセスに転送し、リモートからアクセスできるようにしていました。Tailscale は現在、対応するハンドラーが存在しないサービスポートへのパケットをフィルタリングし、適切な TCP RST 応答で拒否します。この脆弱性は Tailscale バージョン 1.98.9 以降で修正されています。 影響は何でしたか？ Tailscale Service への ACL 許可を持つユーザーは、アドバタイズされていないポートでサービスにアドレス指定し、サービスをホストしているノードのループバックでリッスンしているプロセスに到達できた可能性があります。 誰が影響を受けましたか？ サービスをホストするために使用されるノードでループバックのみのネットワークアクセス制限に依存している Tailscale Services のユーザー。 何をすべきか？ ループバックにバインドされたプロセスと並行してノードで Tailscale Services をホストしている場合は、Tailscale バージョン 1.98.9 以降にアップグレードしてください。 説明: Tailscale SSH は、数値 UID によるユーザーのアドレス指定を許可し、ACL の root ユーザー制限をバイパスしていました。 何が起こったのか？ Tailscale SSH は以前、ユーザー名または UID 値でユーザーをアドレス指定することを許可していましたが、ACL の root ユーザー制限の強制は前者のみを考慮していました。非 root SSH アクセス権を持つユーザーが 0@host にアドレス指定した場合、ACL に違反して root にアクセスできた可能性があります。Tailscale は現在、この曖昧さを避けるために、SSH 経由での UID または数値のみのユーザー名の使用を禁止しています。この脆弱性は Tailscale バージョン 1.98.9 以降で修正されています。 影響は何でしたか？ ノードへの SSH アクセス権を持つユーザーは、ACL ポリシーに違反して、ユーザー名 0 を使用して root として SSH 接続できた可能性があります。 誰が影響を受けましたか？ Tailscale ACL の autogroup:nonroot ユーザー制限に依存している Linux/Unix ホストで Tailscale SSH を使用しているユーザー。 何をすべきか？ Tailscale SSH を使用している場合は、Tailscale バージョン 1.98.9 以降にアップグレードしてください。 謝辞: この問題をご報告いただいた Tim Hoffman (GM) に感謝いたします。 説明: Tailscale Serve Unix ソケットプロキシターゲットは root に制限されておらず、非 root オペレーターが特権ソケットをプロキシできるようになっていました。 何が起こったのか？ Tailscale Serve は、受信接続をローカルバックエンドにプロキシできます。これには、プロキシターゲットとして設定された Unix ドメインソケット（例: proxy: unix:/var/run/docker.sock）が含まれます。ローカルの非 root ユーザーが Tailscale オペレーターとして設定されている場合、LocalAPI を介して Serve 設定を書き込むことができます。Tailscale は、特権昇格を防ぐために、ファイルシステムパスを Serve ターゲットとして指定する機能を root ユーザーに制限していますが、このチェックは Unix ソケットプロキシターゲットには適用されていませんでした。したがって、非 root オペレーターは、root として実行されている tailscaled プロセスに、本来ならアクセスを拒否されるはずのファイルシステム権限をバイパスして、特権 Unix ソケットにプロキシさせることができました。Tailscale は現在、Unix ソケットプロキシターゲットを root ユーザーに制限しており、これはファイルシステムハンドラーに既に適用されている要件と一致しています。この脆弱性は Tailscale バージョン 1.98.9 以降で修正されています。 影響は何でしたか？ Tailscale オペレーターとして設定された非 root ユーザーは、root として実行されている tailscaled プロセスに、本来ならアクセスできない特権 Unix ソケットに接続させることができました。 誰が影響を受けましたか？ 非 root ローカルユーザーが Tailscale オペレーターとして設定されており、特権 Unix ソケット（Docker、containerd、または CRI ソケットなど）が存在する、Tailscale Serve を実行している Linux/Unix ホスト。 何をすべきか？ Tailscale Serve を使用している場合は、Tailscale バージョン 1.98.9 以降にアップグレードしてください。 謝辞: この問題をご報告いただいた Tim Sageser (dtrsecurity) に感謝いたします。 説明: Tailscale SSH Unix ソケットフォワーディングはシンボリックリンクのパーミッションを尊重せず、特権ソケットへのアクセスを許可していました。 何が起こったのか？ Tailscale SSH には、クライアントとホスト間で TCP ソケットと Unix ソケットの両方を転送する機能が含まれています。Tailscale SSH の Unix ソケットフォワーディングにおけるファイルシステムパーミッションチェックのバグにより、権限のないユーザーがリモートホスト上の特権ソケットにバインドしてアクセスできるようになっていました。以前は、Tailscale SSH が要求されたソケットのファイルシステムパーミッションを評価する際、要求されたパスと許可リストおよび拒否リストとの間の字句的な一致のみを実行していました。攻撃者が所有するパス（例: /home/$USER/my.sock）に、保護されたリソース（例: /var/run/docker.sock）を指すシンボリックリンクを作成した場合、SSH 接続で後者のパスにバインドしてアクセスすることが可能でした。これは、Tailscale が root として実行されるため、特権宛先にアクセスできるため可能です。字句的な一致に加えて、Tailscale SSH は現在、要求されたパスと設定されたパスでシンボリックリンクをチェックし、それらの宛先も承認されていることを確認します。許可リストの外部にある宛先を持つシンボリックリンクは拒否されます。この脆弱性は Tailscale バージョン