社内のサーバーに、Tailscale SSHで入れるようにしていますか。セキュリティ研究者のErica Windisch氏(Cyberdione Labs)は10月25日、報告書「Tailworm」を公開しました。VPNソフトのTailscaleと、その管理サーバーを自前で立てるためのheadscaleで、脆弱性11件を再現したという内容です。中心は、承認済みの端末を1台乗っ取った攻撃者が、Tailscale SSHの転送機能を使って、別のサーバーでroot権限を得られるという指摘です。
海外では「未修正」と報じられました。編集部が確かめた10月26日13時(日本時間)の時点で、Tailscaleは修正の一部を公開のソースコードに取り込んでいますが、修正版の配布とセキュリティ告知はまだありません。Tailscale SSHを入れていない会社は、中心の指摘の対象外です。入れている会社は、修正版を待つ間に、SSHを許す範囲を絞れます。
何が報告されたのか
Tailscale SSHは、Tailscaleのソフト(tailscaled)に組み込まれたSSHサーバーです。SSHの鍵やパスワードの代わりに、Tailscaleが端末を認証し、ポリシーファイル(アクセス制御の設定)で接続を許します。サーバーとして動くのは、LinuxとmacOSのオープンソース版のtailscaledだけです。
報告によると、tailscaledはrootで動き、SSHの転送(ssh -Lやssh -Rでunixソケットをつなぐ機能)でも、パスの確認とファイルの操作をrootのまま行います。確認してから実際に操作するまでの間にパスを差し替える競合状態(TOCTOU)と、利用者の権限に切り替えない作りが重なり、一般の利用者のセッションから、rootしか触れないソケットを乗っ取れるとしています。研究者は、コンテナの管理やinitが使うソケットを例に、root権限での操作と、端末をネットワークに登録する認証キーの盗み出しを再現したと書いています。
攻撃者に要るのは、承認済みの端末1台と、その端末からのSSHを許すルール1つです。最初の1台は、Webアプリの脆弱性、悪意のあるnpmやPyPIのパッケージ、フィッシングといった、ふつうの手口で乗っ取られる想定です。研究者も、最初の侵入口をTailscaleが作るわけではないと認めたうえで、1台への侵入がネットワーク全体のroot権限に広がる点を問題にしています。
研究者の試験環境では、ポリシーが許す範囲のすべての端末へ、パスワードも盗んだ鍵も使わずに、1台あたり1秒未満で自動的に広がりました。広がりを止めたのは、送り元と送り先の端末を1対1で指定するルールだけだったといいます。接続先のアカウントをroot以外に限っても、一般の利用者の権限から成り立つため防げず、再認証を求めるcheckモードも、接続した後の転送は止めないとしています。
ほかの4種類は、試験中のアプリコネクター(conn25)、headscale、中継サーバー(DERP)のクライアント、tailscale serveの指摘で、いずれもその機能を使う会社だけが対象です。11件の分け方と修正の状況を、1枚の図にまとめました。
Tailwormの11件を5つの種類に分けた表と、10月26日時点のTailscaleの公開の状況作成: 編集部 / 出典: Tailworm(Cyberdione Labs)、Tailscale Security Bulletins・Changelog、GitHub(tailscale/tailscale・juanfont/headscale)
「未修正」は本当か
配布されている版では、まだ修正されていません。Tailscaleのセキュリティ告知の最新は、10月21日のTS-2026-013(eMudhraの中間CAの鍵の件)です。最新の配布版も、報告が試したのと同じ1.104.2(10月21日)でした。1.104系の修正版を作るブランチにも、1.104.2の後の変更はありません。
一方、GitHubで公開しているソースコードのmainブランチには、10月25日から26日にかけて、Tailscale SSHまわりの変更が約20件取り込まれました。26日12時8分に入った#21942は、転送に使うソケットの接続と作成を、rootのtailscaledではなく、ログインした利用者の権限で動く子プロセスに任せる変更です。報告がOpenSSHやDropbearを例に挙げて勧めていた、転送の前に権限を落とす方式と同じ考え方です。tailscale serveでは、ある設定向けのアプリの権限情報が、別の設定への要求に付く問題もありました。これを修正する変更(#21931、報告の指摘11)も、25日に入っています。
Tailscaleは、これらを報告への対応とは説明していません。掲示板のHacker Newsでは25日ごろ、Tailscaleの社員を名乗る利用者(raggi)が「1日中この対応に取り組んでいて、詳しいことは追って出す」と書き込みました。GitHubで一連の変更を出しているのも、同じ名前の開発者です。海外の解説記事は、Tailscaleの技術担当の幹部がRedditで返答したと伝えていますが、Redditは自動での取得を断っているため、編集部は中身を確認していません。
公表の進め方には、批判も出ています。研究者は同じ掲示板で「報告はしたが、公開の時期は調整していない」と書き、報告書では、インフラはいま危険にさらされており、早く知らせたほうが対策が進むとしています。報告には、Tailscaleの説明書と食い違う点もあります。報告は「どの端末にも全端末の一覧が届く」としていますが、Tailscaleの説明書は、ポリシーで接続を許した端末どうしにだけ鍵を配るとしています。社員を名乗る利用者も、この点はheadscaleとの違いかもしれないと書いています。
headscaleは、報告が試した0.29.5の後、10月24日に0.29.6を出しました。リリースノートには、eMudhraの証明書への対応などはありますが、報告の指摘を修正したという記載はありません。
6〜7月のSSHの告知と同じものか
別のものです。Tailscaleは6〜7月に、Tailscale SSHの脆弱性の告知を4件出しており、どれも1.98.9か1.102.1で修正済みです。今回の報告は、それらの修正を含む1.104.2で試しています。
| 告知 |
公表日 |
中身 |
修正版 |
| TS-2026-004 |
6月3日 |
unixソケットの転送で、シンボリックリンクを使うとrootのソケットに届く |
1.98.9 |
| TS-2026-006 |
6月11日 |
ユーザー名に数字のUID(0)を使うと、rootへの制限をすり抜ける |
1.98.9 |
| TS-2026-009 |
7月13日 |
「-」で始まるユーザー名で、rootのセッションが開く |
1.98.9 |
| TS-2026-010 |
7月24日 |
acceptEnvで渡した環境変数の値が、ほかの利用者やログから見える |
1.102.1 |
TS-2026-004は、今回と同じunixソケットの転送の脆弱性です。6月の修正は、シンボリックリンクの行き先も確かめる処理を足したものでした。報告は、確かめた後にパスを差し替える競合状態で、この確認もすり抜けられるとしています。1.104.2より古い版を使っているなら、まず1.104.2に更新します。10月21日の告知(TS-2026-013)の修正も入っています。
うちの会社は対象になるか
中心の指摘(Tailscale SSHの転送)の対象は、LinuxかmacOSのサーバーでtailscale set --sshを実行し、Tailscale SSHで接続を受け付けている会社です。Tailscale SSHはサーバーごとに有効にする作りで、ポリシーファイルのsshの節に、接続を許すルールがあります。Tailscaleの既定のルールは、利用者が自分の端末にcheckモードで入ることだけを許すものです。編集部の見立てでは、タグを付けたサーバーへの接続を許すように書き換えた会社ほど、許している範囲が広くなっています。
TailscaleをVPNとしてだけ使い、サーバーへはOpenSSHなど別のSSHサーバーで入っている会社は、中心の指摘の対象外です。報告も、OpenSSHは初期設定ではこの種類の問題がないとしています。WindowsやスマートフォンのTailscaleは、Tailscale SSHのサーバーになりません。
ほかの指摘は、機能ごとに対象が分かれます。
- 自前で立てたheadscaleをインターネットに公開している会社は、認証なしで管理サーバーを止められる指摘の対象です。報告は、headscale 0.29.5ではポリシーで転送を止められないとして、SSHを許すルールはすべてrootを渡すのと同じとみなすよう勧めています。
- 試験中のアプリコネクターの方式(conn25)を使っている会社は、コネクターを通ってクラウドのメタデータや社内LANに届く指摘の対象です。
- tailscale serveで、unixソケットへのTCP転送を設定している端末は、管理用のLocalAPIがほかの端末から届く指摘の対象です。
修正版が出るまでに確かめること
- Tailscale SSHを受け付けているサーバーと、ポリシーファイルのsshの節にあるルールを一覧にします。サーバーで
tailscale set --sshを実行したかどうかが分かれ目です。
- 必要のないサーバーでは、
tailscale set --ssh=falseでTailscale SSHを無効にします(Tailscaleの説明書にある手順)。管理の入り口をOpenSSHに戻すなら、鍵の配り方を先に決めておきます。
- 残すサーバーのルールは、送り元と送り先の1対1に書き直します。グループ全体やタグ全体を許すルールはやめ、rootや、パスワードなしでsudoできるアカウントへの接続も許しません。報告は、これだけでは中心の指摘を防げないとしつつ、広がりを止めたのは1対1のルールだったとしています。
- 転送が要らないなら、転送を止める方法もあります。1.104.2の公開のソースコードには、tailscaledに環境変数
TS_SSH_DISABLE_FORWARDINGを渡すと、ポートとunixソケットの転送、エージェント転送の要求を断る処理があります。Linuxのパッケージでは、/etc/default/tailscaledにTS_SSH_DISABLE_FORWARDING=trueを書き足し、tailscaledを再起動する形です。Tailscaleの説明書には載っていない設定で、編集部は動作を試していません。VS CodeのRemote-SSHのように転送を使うツールが動かなくなる恐れもあるため、試験用のサーバーで確かめてから使ってください。報告はSaaS版ならルールごとに転送を断れるとしていますが、編集部が読んだ説明書(Tailscale SSH・ポリシーファイルの書き方)には、その項目は見当たりませんでした。
- headscaleを使っている会社は、管理サーバーをインターネットから切り離し、管理用のネットワークかVPNからだけ届くようにします。報告は、systemdのMemoryMaxでメモリの上限を決める、登録の窓口の前に回数を制限するリバースプロキシを置く、といった対策も挙げています。
- tailscale serveを使う端末では、
tailscale serve statusで設定を表示し、tailscaledのソケットなど、権限の強いunixソケットへのTCP転送がないかを確認します。
- 乗っ取りが疑われる端末は、作り直すだけで済ませず、管理画面から端末を削除します。報告は、rootを取られた端末の鍵のファイルは持ち出された前提で扱い、削除してから認証キーを再発行するよう勧めています。Tailscaleの説明書によると、タグを付けた端末は鍵の有効期限が既定で無効です。サーバーにも期限を設けておくと、盗まれた鍵が使える期間を短くできます。
- 社員には、頼んでいないのにTailscaleの再認証の画面が出たら情シスに知らせるよう伝えます。報告は、攻撃者がcheckモードの再認証を誘う手口も挙げています。
修正版が出たら
Tailscaleのセキュリティ告知のページ(RSSあり)と更新履歴を見て、修正版が出たら、Tailscale SSHを受け付けているサーバーから先に更新します。1.104系の修正版として出るか、次の版で出るかは、まだ分かりません。tailscaledを再起動すると、Tailscale SSHの接続はすべて切れます(Tailscaleの説明書)。更新は、作業の少ない時間帯に回してください。headscaleを使っている会社は、headscaleの次のリリースノートも確かめます。
