Linux カーネルの cgroups v2022 リソース制限メカニズムの実装における脆弱性 (CVE-0492-1) の詳細が公開されました。このメカニズムは、分離されたコンテナーをエスケープするために使用できます。 この問題は Linux カーネル 2.6.24 以降に存在しており、カーネル リリース 5.16.12、5.15.26、5.10.97、5.4.177、4.19.229、4.14.266、および 4.9.301 で修正されました。 Debian、SUSE、Ubuntu、RHEL、Fedora、Gentoo、Arch Linux のページで、ディストリビューション内のパッケージ更新の公開を追跡できます。
この脆弱性は、release_agent ファイル ハンドラーのロジック エラーが原因で、ハンドラーを完全な権限で実行すると適切なチェックが実行されません。 release_agent ファイルは、cgroup 内のプロセスが終了するときにカーネルによって実行されるプログラムを定義するために使用されます。 このプログラムは root として実行され、root 名前空間のすべての「機能」が使用されます。 release_agent 設定には管理者のみがアクセスできると想定されていましたが、実際には、チェックは root ユーザーへのアクセス許可に限定されており、コンテナーからの設定変更や管理者権限 (CAP_SYS_ADMIN) のない root ユーザーによる設定変更は除外されませんでした。 ）。
以前は、このような機能は脆弱性とは認識されませんでしたが、ユーザー名前空間 (ユーザー名前空間) の出現により状況は変わりました。これにより、コンテナー内に、コンテナーの root ユーザーと重複しない別の root ユーザーを作成できるようになります。メイン環境。 したがって、攻撃の場合は、別のユーザー ID 空間に独自の root ユーザーを持つコンテナーに release_agent ハンドラーを接続するだけで十分です。このハンドラーは、プロセスの完了後、メイン環境の完全な権限で実行されます。
デフォルトでは、cgroupfs は読み取り専用モードでコンテナにマウントされますが、CAP_SYS_ADMIN 権限がある場合、または unshare システム コールを使用して別のユーザー名前空間を持つネストされたコンテナを作成することにより、この pseudofs を書き込みモードで再マウントしても問題はありません。 CAP_SYS_ADMIN 権限は、作成されたコンテナに対して使用できます。
この攻撃は、分離されたコンテナーで root 権限を持っている場合、または追加の権限の取得を禁止する no_new_privs フラグを付けずにコンテナーを実行している場合に実行される可能性があります。 システムでは、ユーザー名前空間のサポートが有効になっており (Ubuntu と Fedora ではデフォルトで有効になっていますが、Debian と RHEL では有効になっていません)、ルート cgroup v1 にアクセスできる必要があります (たとえば、Docker はルート RDMA cgroup でコンテナを実行します)。 CAP_SYS_ADMIN 権限を持っている場合にも攻撃は可能です。この場合、ユーザー名前空間のサポートと cgroup v1 ルート階層へのアクセスは必要ありません。
この脆弱性により、隔離されたコンテナからエスケープできるだけでなく、「機能」を持たない root ユーザー、または CAP_DAC_OVERRIDE 権限を持つユーザーによるプロセスの起動も可能になります (攻撃には、ファイル /sys/fs/cgroup/*/release_agent へのアクセスが必要です) root が所有) して、すべてのシステム的な「機能」にアクセスできるようになります。
Seccomp は unshare() システム コールへのアクセスをブロックし、AppArmor と SELinux は書き込みモードでの cgroupfs のマウントを許可しないため、コンテナの追加分離に Seccomp、AppArmor、または SELinux 保護メカニズムを使用する場合には、この脆弱性を悪用することはできないことに注意してください。
出所： オープンネット.ru