Docker EngineとAuthZ認可プラグインに関する10年前の問題が再び出現し、攻撃者がホストシステムへのルートレベルアクセスを取得できるようになる。
研究者らは、攻撃者がDockerEngineの認可プラグインをバイパスしてホストシステムへのルートレベルアクセスを取得できる新しい脆弱性について警告しています。この欠陥は2024年にパッチが当たった別の認可バイパス脆弱性と同じ根本原因を持っていますが、根本的な問題は2016年から知られていました。
CVE-2026-34040として追跡されているこの新しい脆弱性は、CVSSスケールで8.8（高）と評価されており、Docker Engine 29.3.1およびDocker Desktop 4.66.1で修正されました。更新をすぐに展開できない場合、リクエストサイズを512KBに制限することで、悪意のあるリクエストをフィルタリングできる可能性があります。
「ほとんどのエンタープライズデプロイメント、CI/CDシステム、および管理プラットフォームでは、Docker APIはネットワーク（TCP/TLS）を介してアクセスされます」と、セキュリティ企業Cyeraの研究者はレポートで述べています。「これは競合状態やタイミング依存性のない単一のHTTPリクエストです。攻撃者（またはAIエージェント）がAuthZプラグインで制限されたDockerAPIアクセスを持っている場合、それをバイパスできます。」
10年前のAuthZギャップ
Docker Engineはデフォルトではロールベースの認可を持っていません。つまり、Docker APIにアクセスできるユーザーは、すべてのDockerコマンドを実行できます。より細かい制御を実施するために、企業は様々なサードパーティおよびカスタムDockerAuthZプラグインに依存しており、この機能は2016年以来DockerEngineに存在しています。
2018年、研究者らは、攻撃者がContent-Lengthを0に設定したリクエストをDockerデーモンに送信することで、AuthZプラグインで実施されたすべての制限をバイパスできることに気づきました。その後、リクエスト本文を削除してAuthZプラグインに転送されます。プラグインはそれに何もコマンドがないと思って、そのようなリクエストを自動的に承認していたはずですが、DockerEngineはその後、削除されたリクエスト本文のコマンドを実行することになります。
この問題は2019年1月にリリースされたDocker Engine v18.09.1で修正されましたが、修正は19.03以降の後続のDockerEngineバージョンに含まれず、回帰とCVE-2024-41110として追跡される新しい脆弱性が発生しました。この欠陥は最終的に2024年7月にバージョン23.0.14、26.1.4、および27.1.0でパッチが当たりました。
誰も大きすぎるリクエストをチェックしていなかった
以前の認可バイパスはリクエストContent-Lengthが0に設定された場合にトリガーされましたが、リクエストが特定のサイズを超えた場合に同じ関数で何が起こるかを誰もチェックしていませんでした。
「APIリクエスト本文が1MBを超える場合、Dockerのミドルウェアは認可プラグインがそれを見る前に本文を静かにドロップします」と、Cyera研究者は発見しました。「プラグインは検査するものを何も見ないので、リクエストを承認します。Dockerデーモンはその後、完全な本文を処理し、要求されたコンテナを作成し、ホストファイルシステムへの完全なアクセスを許可する可能性があります。」
これは本質的に同じバグクラスで同じ根本原因ですが、ゼロ長の代わりに1MBのリクエストパディングを使用しています。AuthZプラグインがリクエストを検査してブロックできないため、攻撃者はルートアクセス権限を持つ特権コンテナを作成できる機能を含む、すべてのDockerEngineコマンドへのアクセス権を持つことになります。
通常、最も深刻なDocker脆弱性は、攻撃者がコンテナ内から逃げられるものですが、この欠陥はコンテナが作成される前に発生するため、コンテナ内監視ツールは悪用の試みをキャッチできません。ただし、管理者は、例えば512KBを超えるすべてのリクエストをブロックするリバースプロキシを介してAPIリクエストをルーティングできます。これは一時的な軽減です。
公開されたDocker APIインターフェースは、ボットネットと攻撃者によって常に標的にされ、クラウドインスタンスとサーバーをハイジャックしています。特にDockerは世界的に90%以上のエンタープライズ環境で使用されているためです。
Cyera研究者は、journalctl -u docker | grep "Request body is larger than"を使用して潜在的な悪用の兆候をデーモンログで検索することを推奨しています。また、Docker APIアクセス権を持つ自動化されたシステムを確認し、本番資格情報または規制されたデータへのアクセス権を持つホストを優先して即座にパッチを当てることをアドバイスしています。
