新たに公表されたDockerの脆弱性CVE-2026-17106は、悪意あるコンテナがdocker cpで指定された保存先の制限を突破し、Docker CLIを実行しているホスト上のファイルを上書きできてしまうというものです。
この欠陥があっても、コンテナが自動的にホストを完全に制御できるわけではありません。むしろ、コピー出力操作をホスト側での書き込みプリミティブに変換し、それを起動したユーザーや自動化プロセスの権限で動作する形になります。
Impervaの研究者らがDockerのアーカイブ処理パイプラインにこの問題を発見し、Dockerはdocker container cpコマンドにおける保存先エスケープの欠陥としてこれを扱っています。
docker cpは2つのファイルシステム間で直接ファイルを転送するわけではありません。コンテナからホストへのコピーの場合、デーモンが要求されたコンテナ内のパスを走査してtarアーカイブを作成し、そのアーカイブを展開のためCLIへ送信します。
アーカイブの元データはコンテナ側が制御し、ファイルシステム操作自体はホスト側のCLIが実行します。ここでのセキュリティは2つの前提に依存しています。アーカイブが元のファイルシステムの状態を一貫して表していること、そして展開処理がすべてのアーカイブエントリを保存先の外部に解決させないことです。
悪意あるコンテナ内で動作するプロセスは、Dockerがアーカイブを構築している最中にパス名を変更できます。Ron Masas氏が示したところによると、Dockerはあるパスを最初はディレクトリとして記録しながら、アーカイブのメタデータを作成する時点ではシンボリックリンクとして認識してしまうことがあるといいます。
その結果、tarストリームにはシンボリックリンクの後にそのディレクトリの子要素であるかのように見えるエントリが続く形が生じます。これらのレコードは実際のファイルシステムの矛盾した状態を表していますが、クライアントはそのまま処理してしまいます。
クライアント側の展開ロジックがこのエスケープを完成させます。脆弱なコードは、シンボリックリンクが安全かどうかを判定する際に構築済みのパスをチェックしますが、実際にリンクを作成する際にはアーカイブ内の元の値を使用します。
攻撃者はこの不整合を悪用し、選択された出力ディレクトリの外部を指すシンボリックリンクを仕込むことができます。Dockerがその後に続く子エントリを処理すると、オペレーティングシステムは仕込まれたリンクをたどり、攻撃者が制御するファイルをホスト上の外部パスに書き込んでしまいます。
これにより、docker cpを実行したアカウントの権限の範囲内で任意のファイル書き込みが可能になります。macOSでは、Docker DesktopのデーモンはLinux仮想マシン内で動作していますが、CLIによるコピーされたアーカイブの展開処理はMac本体上で行われます。
そのため、悪意あるコンテナは、ローカルユーザーが変更可能なシェルの起動ファイル、SSH設定、ソースツリー、実行ファイル、クラウド設定、あるいはLaunchAgentの永続化ファイルなどを標的にできてしまいます。
Linuxの場合、管理者やCIワーカー、メンテナンスプロセスがsudoでdocker cpを実行していると、影響はさらに大きくなります。Impervaは、この書き込みプリミティブを使ってruncを置き換えることで、Dockerが置き換え後のバイナリを実行した際にroot権限でのコード実行につながり得ることを実証しました。
この脆弱性は、Docker Sandboxesのコピー出力コマンドであるsbx cpにも影響し、AIエージェントが信頼できない成果物を取得する際にリスクを生じさせます。
各組織は、Docker EngineおよびCLIをバージョン29.7.2以降に、Docker Desktopをバージョン4.86.0以降に、Docker Sandboxesをバージョン0.38.0以降にアップグレードすることが推奨されます。
パッチが適用されるまでの間は、実行中または侵害された可能性のあるコンテナから機密性の高いシステムへのコピーを避け、sudoを用いたコピー作業を避け、CIにおいて最小権限の原則を徹底し、フォレンジック資料の収集は隔離された仮想マシンや使い捨てのアカウントを通じて行うようにしてください。
ANY.RUNのブラウザ内データ検査で、検知・調査・対応をより迅速に。 フィッシングの全体像を完全に把握し、SOCを強化してMTTRを削減しましょう
翻訳元: https://cyberpress.org/copyescape-docker-flaw/
