クラウド環境
WSL2上の「Docker Desktop仮想マシン（VM）」から脱出する新たな手口：隔離壁が突破されるリスク
攻撃者がDocker Desktop VMを脱出し、ホスト上で不正なコードを実行する新たな手口について解説します。正規の開発ツールも、内部APIや設定の露出により、リスクを高めてしまいます。
- 「TrendAI™ Research」の調査により、Docker DesktopのWSL2仮想マシン（VM）を脱出し、Windowsホスト上でコードを実行する新たな手口が発見されました。VMの隔壁が必ずしも堅牢なセキュリティ層とはならないことが示されました。
- 今回取り上げるVM脱出の手口は、内部APIや設定情報、コマンドラインインターフェース用プラグインの読み込みなど、Docker Desktopが持つ正規の仕組みを利用したものです。このように、ユーザ向けの機能も、ホストレベルでのコード実行に転用される可能性があります。
- 対策として企業や組織では、開発環境への監視やガバナンスを強化することが重要です。例えばDocker Desktopの設定を検証し、不審なAPI呼び出しや想定外のバイナリ実行がないかを監視することにより、リスクを軽減できます。
Docker Desktop仮想マシンからの脱出
現代のセキュリティでは、緩和策や隔離策、保護策を多層的に組み合わせた方針が取られています。緩和策が攻撃手段の阻止や無効化に重点を置いているのに対し、隔離策は、緩和策が突破された際の影響を狭めることを目的としています。そして、隔離策が導入されていると、「最悪でも隔離措置が効いている」という暗黙の信頼により、セキュリティリスクを甘く見立てる傾向にあります。ですが、その隔離の仕組み自体が破られたとしたら、何が起きるでしょうか。
この観点に基づく研究として本稿では、「Docker Desktop用仮想マシン（VM）」と「Windowsホスト」間の隔壁を破る5つの新たな手口を解説します。対象環境として、Windowsホスト内でLinuxを稼働させるために、「WSL（Windows Subsystem for Linux）」を利用します。
「Docker Desktop」は、ソフトウェアのビルド、テスト、デプロイ準備を効率化する目的で、企業環境に広く導入されています。その重要性から、脆弱性発見コンテスト「Pwn2Own」でも、たびたびハッキング対象とされてきました。例えば、デフォルト権限で「Dockerコンテナ」から脱出することに加え、「Docker Desktop VM」から脱出してホスト上でコードを実行することも、挑戦事項に挙げられています。
ここで注意すべき点は、「Dockerエンジンコンテナからの脱出」と「Docker Desktop VMからの脱出」では、条件や影響が全く異なることです。コンテナからの脱出は通常、Linuxカーネルの脆弱性を悪用するか、不正なコンテナを通してDocker Desktopの脆弱性を悪用することで実現されます。しかし、それに成功しても、WSL環境ではDockerエンジン自体がVMの「内部」で稼働していることもあり、掌握できるのはVM内にとどまります。Windowsホストには到達できません。
「Docker Desktop VM」の実体は、WSLによって起動されるLinuxディストリビューションであり、仮想化システム「Hyper-V」の特殊バージョン上で、隔離状態のゲストOSとして機能します。コンテナ脱出に成功した攻撃者が、続いてWindowsホスト側でカレントユーザ権限によるコード実行を試みる場合、「Docker Desktop VM」から「ホスト側」に脱出する必要があります。過去のPwn2Ownコンテストでも、当該VMからの脱出手法がいくつか提示されていましたが、そこではLinux版のDocker Desktopが使用されていました。一方、本調査はWindows版のDocker Desktopを対象としており、バックエンドにWSL2を用いる構成としています。
本稿では、Docker Desktop VMからの脱出手段となりうる5種の攻撃パターンを取り上げます。はじめに、WSL環境におけるDocker Desktopのアーキテクチャや、WindowsホストとDocker Desktop VM間の通信に関わる内部コンポーネントについて説明します。以降、その内容を土台として、各攻撃パターンの詳細を解説します。
前提条件として、Docker Desktop VMを脱出するには、前もってDockerエンジンコンテナの脱出か、Dockerデーモンへのアクセスを実現している必要があります。本稿で述べる手法は、Windowsホスト上でWSL2のバックエンドを使用し、かつ、TCP経由でDockerデーモンを公開している場合にのみ有効です。また、これらの手法はDockerソケットを利用するものではありません。
本調査では、VM脱出を実演するにあたり、コンテナ脱出の手法そのものに焦点を当てていません。代わりに、Docker Desktop VMのルートファイルシステムをコンテナ内部にバインドマウントすることで、コンテナ脱出済みの状態を擬似的に作り出しています。WSL環境下のDocker Desktopであれば、実際に非特権コンテナからの脱出に成功した場合も、今回の疑似コンテナ脱出を行った場合も、内部Docker APIへのアクセスが可能になる点に変わりはありません。
調査環境として、WSL2上でDocker Desktop for Windowsのバージョン4.42を動作させました。付録に記載の通り、発見事項はすべてDockerセキュリティチームに報告済みです。
WSL環境におけるDocker Desktopのアーキテクチャ
本セクションでは、WSL環境で動くように設定されたDocker Desktopのアーキテクチャについて、簡単に解説します。発見されたDocker VM脱出の手法はすべて、この設定下で発生するものです。
WSLを用いる場合、Docker Desktop for Windowsは、「Docker Desktop VM」の内部でコンテナを動作させます。このコンテナは図1のように、Windowsホストから「二重に隔離」された状態となります。詳細なセットアップとして、WSLは、Docker社が管理する「WSL用Linuxディストリビューション」を元に、Docker Desktop VMを作成します。その際、Windowsの「ホストコンピューティングシステム（HCS）API」を呼び出します。HCS APIは、「Hyper-V Host Computeサービス」の配下にあるVMを管理するものです。
Dockerコンテナは、Dockerコンテナエンジンが管理する「隔離層」の内側に位置しています。これに対して攻撃者は、不正なコンテナを通してカーネルの脆弱性などを悪用し、外側のDocker Desktop VMに「脱出」します。すると、当該VMがWindowsのカレントユーザ権限で動いていることもあり、ホストに対して多少の操作を実行できるようになります。例えば、カレントユーザ権限で書き込み可能なフォルダに対して「任意のファイルを出力」できる可能性があります。しかし、ホスト上でコードを直接実行するようなことは、難しいでしょう。
また、スタートアップ用のファイルを書き込んでおき、端末が正規ユーザによって再起動されるのを待つことで、コード実行を達成するケースも考えられます。しかし、攻撃者としては、Windowsの再起動を待たずにコードを実行したいところです。そのためには、Docker Desktop VMを掌握しているだけでは不十分であり、新たな手口を見出す必要があります。実際に過去のPwn2Ownコンテストでも、Docker VMからの脱出を意図して、少なくとも2つの手法が試されていました。
Docker Desktopのホスト-VM間通信
Docker Desktop for Windowsは、機能別にさまざまなAPIを構えた複雑なアーキテクチャを採用しています。たとえば、コンテナ管理やモジュール管理、拡張機能の管理のために、それぞれ異なるAPIが用意されています。こうしたAPIに対応する接続先エンドポイントの大半が、図2に示すように、Docker Desktop VM内部の「Linuxソケット」を通じて公開されています。
Dockerエンジンは、このソケットを通じてAPIコマンドを受け付けます。注目すべきは、当該ソケットの機能がDocker Desktop VMの「内部」からも呼び出し可能という点であり、そこを経由することで、ホスト側のDocker Desktopコンポーネントを呼び出せるようになります。デフォルトのインストール構成では、全てのDockerコンポーネントがカレントユーザの権限で動作します（一部の特殊な構成を除く）。今回アーキテクチャを調査した結果、図3のように、Docker機能に関連するソケットが40個以上確認されました。
図3をみると、「backend.sock」や「module-manager.sock」などのソケットがあり、これらは攻撃者にとって有力な標的となり得ます。また、WSL環境下のDocker Desktop VMは、Windowsホストのルートファイルシステムを「/mnt/host/c」にマウントすることが知られています。このファイルシステムへのアクセスについては、カレントユーザの権限範囲内で許可されます。図4に、Docker Desktop VM内部にいる攻撃者から見たアタックサーフェス（攻撃対象領域）を示します。
図4からわかるように、攻撃者はホスト上で直接コードを実行することはできませんが、ホスト側にも顕著な露出箇所が存在します。それは、書き込み権限のある場所に実行可能ファイルを配置できることです。ただ、それを攻撃者自身の手で実行することはできません。
以降では、VM内の各種ソケットや、それを通じて公開されるAPIについて解説します。また、攻撃者によるコード実行を可能にする仕組みとして、VM内の「Linuxソケット」と「マウント済みファイルシステム」を組み合わせ、意図的に副作用を発生させる手口について説明します。
WSLバックエンドのDocker Desktop VMが公開するAPI
Docker Desktopは、そのコンポーネントAPIのほぼすべてを、VM内部のLinuxソケットとして公開しています。これらのAPIはドキュメントとして明文化されていませんが、Dockerエンジン用APIとの間に一定の共通点が見られます。その仕様や機能はDockerバイナリのリバースエンジニアリングによって解析できますが、多くの場合、ソケットに直接アクセスするだけでも把握可能です。具体的には、試行錯誤で対象ソケットにリクエストを送り、ホスト側での挙動を逐次確認することになります。
まず、ソケット「backend.sock」に下記のように簡単なリクエストを送ったところ、対応するバックエンドAPIの「エンドポイント一覧」が表示されました。
図5に、表示されたエンドポイント一覧の例を示します。その内容から、各エンドポイントのパスや、対応するHTTPメソッドを確認できます。
これらのエンドポイントは、Dockerのバージョンによって変わる可能性があります。調査時点では、バックエンドAPIのエンドポイント約200個が確認されました。そのすべてがDocker Desktop VM内で公開されており、Docker Desktopの環境やアプリケーションを制御するために使用できる状態となっています。実際にエンドポイントを呼び出す際には、適切なURLパラメータを把握する必要があります（特にPOSTリクエストの場合）。
今回、さまざまなバックエンド用APIのエンドポイントを通じてDocker Desktop環境を操作し、カレントユーザ権限下でホスト上のコードを直接実行できるかどうか、調べました。結果、対象エンドポイントのいずれを通しても、攻撃者が自前で用意したバイナリを直接実行するような経路は見当たりませんでした。そこで方針を切り替え、Docker Desktopの挙動を利用し、攻撃者のバイナリを「間接的」に実行する手段を探ってみました。
バックエンドAPIとDockerの設定
VM内部で公開されているAPIエンドポイントのうち、Docker Desktopの設定に関するものとして「/app/settings」と「/app/settings/flat」の2種が確認されました。それぞれ、以下のコマンドでアクセス可能です。
上記コマンドにより、すべての設定項目名と、対応する値をJSON形式で取得できます（図6）。Dockerのバージョン4.42（195023）では、約161種類の設定項目が存在します。また、こうしたエンドポイントはPOSTメソッドにも対応しており、Docker Desktopの設定を変更することも可能です。
調査中に、エンドポイント「/app/settings/flat」から奇妙な動きが確認されました。本来、このエンドポイントはJSONデータをフラット（flat）な形式で返すだけのものと予想されましたが、実際には、「/app/settings」の時と異なる設定項目が返されました。その中身を調べたところ、悪用の手がかりとなりそうなものがいくつか発見されました。さらに、「/app/settings」へのPOSTリクエストによって変更可能なことも判明しました。
Docker Desktop VMの脱出
以降、VM脱出の手口について解説します。前提として、攻撃者はすでにカーネルの脆弱性やDockerアーキテクチャの弱点を悪用し、コンテナからの脱出に成功したものと想定します。こうしてコンテナ脱出を行い、Docker VMのファイルシステムにアクセス可能となった状態は、下記コマンドで容易に再現できます。
上記コマンドにより、新たに起動したコンテナ内の「/vm_root」に、Docker用Linuxディストリビューション（Docker Desktop VM）のルートディレクトリがマウントされます。この後、コンテナのシェルから通信コマンド「curl」を用いることで、ソケット経由でエンドポイントにリクエストを送ることが可能です。以降に述べるVM脱出の各手法は、すべてこのコマンドを起点として利用しています。
認証情報ヘルパー（credentialHelper）を利用したVM脱出
前述のとおり、以下のエンドポイントでは返される設定項目が異なりますが、
/app/settings
/app/settings/flat
どちらも「/app/settings」へのPOSTリクエストによって変更が可能です。最初に述べるVM脱出の手法は、こうした設定変更の仕組みと、VM内部のLinuxソケットを併用したものです。
「/app/settings/flat」にだけ存在して「/app/settings」に含まれない設定項目の中で、特に目を引くのが以下のものです。
credentialHelper（認証情報ヘルパー）
そのデフォルト値は図7のように、以下の実行ファイルを指しています。
docker-credential-wincred.exe
Dockerは、コンテナレジストリへのログイン認証情報などを安全に保管する仕組みを、モジュール方式（切り替え可能）で実現しています。Docker独自の認証情報管理モジュールは「Wincred」と呼ばれ、デフォルトでの実行パスは以下のようになっています。
C:\Program Files\Docker\resources\bin\docker-credential-wincred.exe
このパスは保護されているため、カレントユーザが管理者権限を持っていない限り、中にあるファイルを書き換えることはできません。しかし、パスの設定自体であれば、下記のコマンドで容易に変更できてしまいます。
本コマンドにより、設定項目「credentialHelper」は下記の値（パス）に変更されます。
C:\Users\sec.docker\calc.exe
カレントユーザは、自身の権限の高低に関わらず、このパス内を自由に編集することが可能です。そのため、低権限の攻撃者であっても、下記の3手順によってVM脱出とコード実行を達成できます。
- 偽の認証情報ヘルパーを配置可能なパスを確保する。
- 設定項目「credentialHelper」の値を、新しいパスに変更する。
- VM内部から「別のエンドポイント」を使用し、Docker Desktopに偽の認証情報ヘルパーを強制実行させる。認証情報ヘルパーはWindowsホスト上で実行されるため、VM脱出の目的が達成される。
手順1と2は、先に述べた通り、「credentialHelper」の値をユーザ管理下のパスに書き換えることで達成できます。残る課題は、手順3です。正規の利用者による操作を待つことなく、Docker Desktopに偽の認証情報ヘルパーを強制実行させるには、どうすればよいでしょうか。
前述のとおり、バックエンドAPIには、VM内部からDocker Desktopを制御するためのエンドポイントが多数存在します。例えば、以下のようなものがあります。
- /engine/stop：Dockerサービスを停止
- /engine/start：Dockerサービスを開始
- /engine/restart：Dockerサービスを再起動
- /app/quit：Docker Desktopを終了
- /app/reset：Docker Desktopの全設定をリセット
これらのエンドポイントはいずれもDocker Desktopの動きを制御するものであり、VM内部から呼び出しても、ホスト側に影響を及ぼします。例えば、Dockerのバックエンドサービスを強制的に再起動し、設定を再度読み込ませます。エンドポイント「/app/reset」を用いた場合、すべての設定がリセットされます。
調査を進めたところ、ホスト側のDockerバックエンドサービスを通して認証情報ヘルパーを実行させるという「副作用」を有するAPIが見つかりました。具体的には、VMからエンドポイント「/kubernetes/start」を呼び出すことにより、ホスト側では以下の実行ファイル（「credentialHelper」として設定したパス）が起動しました。
C:\Users\sec.docker\calc.exe
これにより、Docker Desktop VMの脱出が成立したことになります。エンドポイント呼び出しのコマンドは、以下の通りです。
図8の通り、エンドポイント「/kubernetes/start」を呼び出すと、その副作用として、Dockerのバックエンドサービスが「calc.exe」を実行します。
以上のように、攻撃者がコンテナを脱出してDocker Desktop VMに到達したのであれば、Docker Desktopの設定を編集し、副作用のあるエンドポイント（例：/kubernetes/start）を呼び出すことで、ホスト側でコードを実行させることが可能です。この際、正規利用者の操作を待つ必要はありません。以降に述べる追加の手口においても、「カレントユーザによって編集可能なパス」と「バックエンドAPIの副作用」を用いる点は同様ですが、対象のパスやAPIが異なります。
Docker CLIプラグインを利用したVM脱出
Dockerは、プラグインによる拡張型アーキテクチャを備えています。Windows版のDockerコマンドライン・インターフェース（CLI）である「docker.exe」には、あらかじめプラグインの一式が定義されています。そして、CLIに渡されたコマンドに応じて、対応するプラグインが起動し、必要な処理を行います。また、ユーザ側で独自に作成したプラグインを追加することも可能です。デフォルト設定の場合、プラグインの一式は、下記に示す「プログラムフォルダ」の配下にインストールされています。
C:\Program Files\Docker\cli-plugins
カレントユーザでは、当該フォルダに対する変更権限がありません。そのため、これらのプラグインを改ざんしてVM脱出に利用することはできません。
以降で述べる手口では、WSLによるコマンド実行機能を一切使用していません。代わりに、Docker Desktop固有のコンポーネントを利用することで、ホスト上でのコマンド実行を達成します。
調査に基づくと、Docker Desktopは、下記の「ユーザフォルダ」からもプラグインを読み込みます。
C:\Users{ユーザ名}.docker\cli-plugins\
このフォルダはカレントユーザの管理下にあるため、VM脱出に悪用できる可能性があります。
Docker CLIプラグインの読み込み処理
Docker Desktopの初期化時、Dockerのバックエンドはデフォルトのプラグイン（図9参照）をコマンドラインオプション「docker-cli-plugin-metadata」付きで実行します。これにより、各プラグインのバージョン情報を取得します（図10）。
また、先述したユーザフォルダに格納されたデフォルトプラグインについても、バージョン情報を取得する目的で、同じオプションを渡して実行します。こうして、新しいバージョンのプラグインを選択して用いる仕組みとなっています。図11は、両フォルダのプラグインが呼び出される様子を示します。
この動作は、Docker Desktopの起動タイミングで発生します。ユーザフォルダ配下とプログラムフォルダ配下に同一のデフォルトプラグインが存在する場合も、特定の操作を通すことにより、双方とも呼び出されます。
CLIプラグインを利用したVM脱出：エンドポイント「/app/reset」
CLIプラグインによるVM脱出は、下記のユーザフォルダを作成し、そこに実行ファイルを配置（図12）することで実現します。
C:\Users{ユーザ名}.docker\cli-plugins
この後、バックエンドAPIのエンドポイント「/app/reset」を呼び出すだけで、これら新規実行ファイルを起動させることが可能です。エンドポイント呼び出しのコマンドは、下記の通りです。
今回の実験では、「calc.exe（電卓）」のコピーを各デフォルトプラグインと同じ名前で用意し、ユーザフォルダ配下に格納しました。結果、図13の通り、ユーザフォルダから続々とプラグインに扮した電卓が起動しました。
プラグインの仕組みは非常に柔軟性が高く、Docker Desktopの重要な構成様式となっています。そのため、「/app/reset」以外にも、VM脱出に悪用可能なエンドポイントが存在する可能性があります。
CLIプラグインを利用したVM脱出：エンドポイント「/modules/apply-updates」
Docker Desktop VM内では、これまで取り上げたバックエンド管理ソケット「backend.sock」の他、モジュール管理ソケット「modules-manager.sock」も公開されており、下記エンドポイントを持つことが分かりました。
- /modules/apply-updates
- /modules/reset-updates
エンドポイント「/modules/apply-updates」については、Dockerバックエンドサービスにプラグインを実行させるという副作用があります。先程と同様、ユーザフォルダ側に改変版プラグインを配置した上で本エンドポイントを呼び出すことで、VM脱出が可能です。エンドポイント呼び出しのコマンドは、下記の通りです。
- HTTP GET "/system/editor"：現在設定されているコードエディタの情報を取得する。
- HTTP POST "/system/editor"：現在設定されているコードエディタをホスト上で起動する。
このAPIには、GETメソッドとPOSTメソッドの2種類があります。POST版は、Docker Desktopに設定された「Editor」をホスト上で起動します。もしカレントユーザがEditorの実行パスを変更できるのであれば、不正なアプリケーションを指定することで、VM脱出が可能になります。しかし、本APIのエンドポイント自体には、実行パスを変更するような機能がありません。ホスト側にコードエディタがインストールされていない場合は、GETリクエストのレスポンスは「no editor found（エディタが見つかりません）」となります。
ところが、Docker Desktopはデフォルトで「VSCode」をEditorとして用いる設定になっています。仮にVSCodeがインストールされていない場合も、同様です。この状態でPOSTリクエストを送ると、Docker DesktopはEditorであるVSCodeの起動を試みますが、インストールされていないため、下記の場所から実行ファイル「Code.exe」を順次検索します。
- C:\Windows\System32\
- C:\Program Files\Docker\Docker\resources\bin\
- C:\Windows\
- C:\Windows\System32\wbem\
- C:\Windows\System32\WindowsPowerShell\v1.0\
- C:\Users{ユーザ名}\AppData\Local\Microsoft\WindowsApps\
Docker Desktopは上記のようなパス解決の仕組みを通して、「Editor」に対応する実行ファイルを検索・起動します。上記パスのうち、特に6番目は、カレントユーザでも書き込み可能なフォルダです。そのため攻撃者は、不正な実行ファイルに「Code.exe」という名前を付け、当該フォルダに配置することを考えます。ここで、検索パスの1番目から5番目にCode.exeが見つからない場合（VSCodeが未インストール）、不正なバージョンの「Code.exe」が実行されることになり、VM脱出が成立します（図14）。具体的な手順は、下記の通りです。
不正な実行ファイルを「Code.exe」の名前でフォルダ「C:\Users{ユーザ名}\AppData\Local\Microsoft\WindowsApps\」に保存する。
「Editor」のエンドポイントにPOSTリクエストを送信する。
まとめと推奨事項
WSL環境のDocker Desktop for Windowsは、ホストとコンテナの間にもう1つの隔離層（VM）を設けています。このため、攻撃者がコンテナを脱出しても、ホスト上で直接コードを実行することはできないように見えます。しかし、Docker Desktopのアーキテクチャ自体は、そもそも「VM脱出」を防ぐように設計されていません。VM内部に公開されたエンドポイントとDocker Desktop固有の機能を組み合わせることにより、VMを脱出する方法が複数存在します。
公開されているエンドポイント自体に、ホスト上で直接コードを実行する機能はありません。しかし、ホストからマウントされたドライブと組み合わせることで、Dockerの動きを巧みに調整し、VM脱出が可能となります。こうした手口は攻撃者にとって、監視されやすいDockerのコード実行機能を使わずに済む点で、利点があります。本稿で述べた手法はいずれも、ログ上は正規の操作として記録されるため、監視をかわしながらコードの実行に至る可能性が高まります。
調査結果を踏まえると、開発ツールに対するセキュリティ上の扱いを今一度見直す必要があると考えられます。Docker Desktopの内部APIや設定方式は、利便性やオーケストレーションを考慮して作られたものであり、堅牢なセキュリティ境界のために構築されているわけではありません。セキュリティチームでは、監視やガバナンスの範囲を開発環境に拡大することを推奨します。直接的なコード実行をブロックするだけでなく、正規なDockerワークフローの悪用を検知できるように、設定管理や挙動監視を強化することが重要な鍵となります。
なお、Docker社は、今回の権限昇格に関わる動作をセキュリティ脅威モデルの範囲外と判断しており、対処などは行わないものとしています。しかし、今回発見された手法は依然として侵害経路となるものであり、特に、不正なDocker Composeプロジェクトやその改ざん版を通して悪用される恐れがあります。
本稿で示した攻撃手法を踏まえ、防御側では、「開発ワークフローにおける実行前のリスク」と「開発環境における脱出後の動き」の両面に対応していくことが求められます。
- TrendAI Vision One™ Code Security（プロアクティブな検知）：セキュリティプラットフォーム「TrendAI Vision One™」の機能「Code Security」は、Docker ComposeのYAMLファイルを検査し、開発環境で使用される前の早い段階で、不審なイメージや危険なマウント指定を的確に検知します。本稿で示した脱出シナリオの多くは不正なCompose設定から始まるため、「コードによる設定（CaC：Configuration as Code）」や「コードによるインフラ構成（IaC：Infrastructure as Code）」を早期に検査することが、予防的防衛策として有効です。
- TrendAI Vision One™ XDR for Endpoints（最終防衛線）：本稿で挙げたVM脱出手法はいずれも、最終的にWindowsホスト上でのコード実行に至ります。そのため、防衛対策上、エンドポイントの可視化は不可欠です。「XDR for Endpoints」は、Docker Desktopの異常な動作、予期しないプロセス起動（ユーザ管理下にあるプラグインパスや認証情報ヘルパーからの起動など）、さらに情報窃取活動、認証情報アクセス、永続化といったマルウェアの動きを検知できます。
- TrendAI Vision One™ Container Security（追加の防衛策）：「Container Security」はDocker Desktop固有のVM脱出を直接的に防止するものではありませんが、許可対象のイメージやマウント、権限に関するポリシーを適用することで、攻撃の足がかりとなる要素を大幅に削減できます。これにより、環境レベルでの防衛層が拡充されます。
付録
TrendAI™は、今回の問題について「責任ある開示（Responsible Disclosure）」の手順に従ってDocker社に報告しました。これに対してDocker社は、指摘にあがった全てのケースを検証し、再現可能であるという認識を示しました。ただし最終的に、当該シナリオはDocker社が定めるセキュリティ脅威モデルの対象外であると判断しました。
具体的にDocker社は、以下の見解を示しました。
前提条件となっている「Docker Desktopのファイルシステム全体を稼働中のコンテナにマウントする」という操作自体が、「すでに攻撃者がホスト上で特権的なシステムレベルのアクセスを持っている」ことを意味します。このレベルのアクセス権があれば、Docker固有の仕組みに頼らなくても、機密情報の読み取り、認証トークンの窃取、基幹システムコンポーネントの操作といった行為が、本質的に可能です。アタックサーフェスに到達できるのは、そうした侵害が成立した後に限られます。そのため、今回報告されたVM脱出の動作は、修正を要する固有の脆弱性には該当しないものと判断します。[KS1]
Docker社は特に、「Docker Desktopのセキュリティ保証は、ホスト自体が侵害されていないことを前提にしている」こと、そして「攻撃者がすでに高い権限を得ている状況には適用されない」点を述べています。なお、当該ケースに対する修正の予定はないものの、本調査の意義については理解を示しました。また、「ホストの安全性が失われた場合に、正規のオーケストレーション機構が悪用される経路を把握する上で、今回のような調査報告は有益である」という評価を付け加えました。
参考記事
Cracking the Isolation - Novel Docker Desktop VM Escape Techniques Under WSL2
By: Nelson William Gamazo Sanchez (Senior Cloud Threat Researcher, TrendAI™ Research) and Nitesh Surana (Senior Threat Researcher, TrendAI™ Research)
翻訳：清水 浩平（Platform Marketing, Trend Micro™ Research）