Docker DesktopのWSL2版で隔離を回避、修正版あり
Windows版Docker DesktopのWSL2環境で、コンテナからWindows側のファイルに届いてしまう脆弱性が公表されました。Docker Desktop 4.98.0以降とWSL 3.0.3以降の両方へ、開発機を更新してください。
急ぎ度: 早めに
CVSS v4は9.2で修正版も出ていますが、直るのはDocker DesktopとWSLの両方を更新した場合だけで、片方では残ります。
関係があるか
Windows上のDocker DesktopでWSL2バックエンドを使い、x86-64のパソコンでコンテナを動かしている開発者の端末や検証用の端末が対象です。LinuxKitベースのバックエンドは影響を受けません。
| 製品 | 影響を受ける版 | 修正版 |
|---|---|---|
| Docker Desktop for Windows（WSL2バックエンド、x86-64） | 4.98.0より前。4.98.0以降でも、WSLが3.0.3より前なら影響が残ります | Docker Desktop 4.98.0以降、かつWSL 3.0.3以降 |
確かめ方
- 1Docker Desktopの設定で、WSL 2 based engineを使っているかを確認します。使っていなければ対象外です。
- 2
docker versionか、Docker Desktopの画面から版を確認します。4.98.0より前なら更新が必要です。 - 3PowerShellで
wsl --versionを実行し、WSLの版を確認します。3.0.3より前なら、Docker Desktopが新しくても影響が残ります。 - 4社内に配布している端末の台帳や資産管理ツールで、Docker Desktopが入っている端末を洗い出します。
何が起きたか
Windows版Docker DesktopのWSL2バックエンドに、コンテナの隔離をすり抜けられる脆弱性が見つかりました。権限を持たない通常のコンテナからでも、ホスト向けのサービスや、ログイン中のWindowsユーザーが読めるファイルに届いてしまいます。
コンテナには、使える呼び出しを絞るseccompの既定設定があります。この設定はAF_VSOCKという、仮想マシンとホストの間の通信に使うソケットを制限しています。ところが32ビット用のsocketcallという呼び出しを経由すると、この制限が効きません。
影響するのはx86-64のWSL2です。修正には、Docker Desktop側とWSL側の両方の更新が必要です。Docker Desktop 4.98.0以降でも古いWSLで動かしていれば、脆弱性は残ります。
攻撃の流れ
-
1
コンテナで実行
権限を持たない通常のコンテナの中で、処理を動かせる状態から始まります。
-
2
既定の制限を回避
32ビット用の呼び出し経路を通ると、AF_VSOCKに対するseccompの制限が働きません。
-
3
ホスト側に到達
仮想マシンとホストの間の通信口に、コンテナから届くようになります。
-
4
情報が露出
ホスト向けのサービスと、ログイン中のユーザーが読めるWindowsのファイルが露出します。
どう悪用されるか
CVSS v4のベクターでは、攻撃元の区分はローカル、必要な権限は低、利用者の操作は不要です。つまり、攻撃する側が対象の端末でコンテナを動かせることが前提になります。外部から直接狙われる種類の脆弱性ではありません。
悪用されると、コンテナの外にあるはずのホスト向けサービスと、ログイン中のWindowsユーザーが触れるファイルが露出します。CVSS v4では機密性と完全性の影響がどちらも高く評価されており、読み取られるだけでなく書き換えられる懸念もあります。開発者が出所の不明なイメージや、第三者が用意したコンテナを動かす環境ほど、この前提は現実的になります。
今すぐやること
-
1
対象の端末を洗い出す
WSL2バックエンドでDocker Desktopを使っている端末を、台帳や資産管理ツールから一覧にします。端末ごとにDocker DesktopとWSLの版も控えておきます。
wsl --version -
2
Docker Desktopを更新する
4.98.0以降の修正版に更新します。配布方法や更新の可否は、ベンダーのリリースノートも確認して社内の手順に合わせます。
docker version -
3
WSLも3.0.3以降にする
Docker Desktopだけを更新しても、WSLが古ければ影響が残ります。WSL側の更新手順と修正内容は、MicrosoftのWSLのリリース情報で確認してください。
-
4
更新後に版を再確認する
Docker Desktopが4.98.0以降、WSLが3.0.3以降になっていることを端末ごとに確かめ、更新が終わっていない端末を洗い出します。
wsl --version -
5
更新が遅れた端末の使われ方を聞く
更新前の端末で、出所の不明なイメージを動かしていないかを利用者に聞き取ります。心当たりがあれば、そのユーザーのWindows上のファイルに不審な変更がないかを調べます。
すぐ更新できないとき
すぐに更新できない端末では、出所の不明なイメージや第三者が用意したコンテナを動かさないでください。ベンダーの告知に回避策が書かれていないかも、あわせて確認してください。
背景
Windows版Docker Desktopは、WSL2上のLinux環境でコンテナを動かします。開発者のパソコンでは、外部から取得したイメージをそのまま動かす場面が多く、コンテナがWindows側と分けられていることが安全の前提です。seccompは、その分離を支える既定の仕組みで、コンテナが使える呼び出しを絞っています。
今回の脆弱性では、AF_VSOCKを止めるはずの規則が、32ビット用の呼び出し経路では効きませんでした。AF_VSOCKは、仮想マシンとホストが通信するためのソケットです。64ビット向けに書いた制限が32ビット互換の入口では効かないことがある、というのは、seccompを使う環境で以前から知られた注意点です。
よくある質問
Q.Linuxサーバー上のDockerやMac版のDocker Desktopも対象ですか。
この記事は、取得元の公開情報をもとに、人が監修しながらAIを活用して執筆しています。執筆と監修は佐々木 航が担い、公開したあとも人が内容を確認しています。誤りに気づいたときは直し、記事の末尾に訂正の行を残します。対応を決める前に、下の原文と参照先も確認してください。
原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。
In Docker Desktop for Windows with the WSL2 backend, an unprivileged Linux container can use 32-bit socketcall to bypass the default seccomp restriction on AF_VSOCK. This can expose host-facing services and Windows files accessible to the logged-in user. The issue affects x86-64 WSL2; LinuxKit-based backends are unaffected. The issue is fully fixed only with Docker Desktop 4.98.0 or later and WSL 3.0.3 or later. Docker Desktop 4.98.0 or later running on an older WSL remains affected.
出典: CVE.org (CVE Program・cvelistV5) NVD GitHub Advisory
参照URL
- advisory nvd.nist.gov
- advisory github.com
- web security@docker.com
- web security@docker.com
- web security@docker.com
- web github.com