sofianehamlaoui/cve-2022-0492-checkerCVE-2022-0492によるコンテナエスケープに対してコンテナ環境が脆弱かどうかをチェックするスクリプト
コンテナ環境が CVE-2022-0492 によるコンテナエスケープに対して脆弱かどうかをチェックするスクリプトです。
2月4日、Linux はカーネルにおける新しい特権昇格の脆弱性である CVE-2022-0492 を発表しました。
CVE-2022-0492 は、コントロールグループ（cgroups）における論理バグです。cgroups はコンテナの基本的な構成要素となる Linux 機能です。この問題は、最近発見された Linux の特権昇格の中でも最も単純なものの1つとして際立っています。Linux カーネルが、特権を必要とする操作を非特権ユーザーに誤って公開してしまったのです。
幸いなことに、ほとんどのコンテナ環境におけるデフォルトのセキュリティ強化は、コンテナエスケープを防ぐのに十分です。AppArmor または SELinux を有効にして実行されているコンテナは保護されます。とはいえ、ベストプラクティスに沿った強化を行わずにコンテナを実行している場合や、追加の権限を付与している場合は、リスクがある可能性があります。「Am I Affected?」セクションには、脆弱なコンテナ構成が列挙されており、コンテナ環境が脆弱かどうかをテストする方法が説明されています。
コンテナ以外にも、この脆弱性により、ケーパビリティを持たない root ホストプロセスや、CAP_DAC_OVERRIDE ケーパビリティを持つ非 root ホストプロセスが、特権を昇格させてすべてのケーパビリティを取得できる可能性があります。これにより、攻撃者は、侵害発生時の影響を制限するためにケーパビリティをドロップするという、特定のサービスで使用されるセキュリティ強化策を回避できる可能性があります。
CVE-2022-0492 は、悪意のあるコンテナがエスケープできるようにする、ここ数か月で3番目となるカーネル脆弱性です。これら3つの脆弱性すべてにおいて、Seccomp と AppArmor または SELinux のいずれかでコンテナを保護すれば、コンテナエスケープを防ぐのに十分でした。
cgroupfs をマウントするには、現在の cgroup 名前空間をホストしているユーザー名前空間における CAP_SYS_ADMIN ケーパビリティが必要です。デフォルトでは、コンテナは CAP_SYS_ADMIM なしで実行されるため、初期ユーザー名前空間では cgroupfs をマウントできません。しかし、unshare() システムコールを通じて、コンテナは CAP_SYS_ADMIN ケーパビリティを持つ新しいユーザー名前空間と cgroup 名前空間を作成し、cgroupfs をマウントできます。
図 1 - 新しいユーザー名前空間を作成し、その中で CAP_SYS_ADMIN ケーパビリティを保持するコンテナ。
すべてのコンテナが新しいユーザー名前空間を作成できるわけではありません。基盤となるホストで非特権ユーザー名前空間が有効になっている必要があります。これは、例えば最近の Ubuntu リリースではデフォルトです。Seccomp は unshare() システムコールをブロックするため、新しいユーザー名前空間を作成できるのは Seccomp なしで実行されているコンテナだけです。添付のスクリーンショットに示されているコンテナは、Seccomp、AppArmor または SELinux なしで実行されています。
図 2 - 新しいユーザー名前空間と cgroup 名前空間にメモリ cgroup をマウントするコンテナ。
上のスクリーンショットでは、コンテナはメモリ cgroup のマウントに成功していますが、release_agent ファイルがマウントされたディレクトリに含まれていないことに気付くでしょう。
前述のとおり、release_agent ファイルはルート cgroup でのみ表示されます。cgroup 名前空間内で cgroupfs をマウントする場合の注意点は、ルート cgroup ではなく、自分が属する cgroup をマウントすることです。
図 3 - 新しいユーザー名前空間と cgroup 名前空間にルート RDMA cgroup をマウントするコンテナ。
この問題を悪用するには、悪意のあるリリースエージェントを release_agent ファイルに書き込む必要があります。上の 図 3 にあるように、このファイルは root が所有しているため、root コンテナプロセスのみがリリースエージェントを設定できます。図 4 はリリースエージェントを設定するコンテナを示し、図 5 は非 root コンテナが設定に失敗する様子を示しています。
図 4 - リリースエージェントを設定する root コンテナ。
図 5 - 非 root コンテナはリリースエージェントを設定できない。
エスケープの最終ステップは、設定済みの release_agent を呼び出すことであり、これには特権は必要ありません。このステップは常に実行可能であるため、環境が CVE-2022-0492 に対して脆弱かどうかには影響せず、そのため省略することにしました。完全なエクスプロイトがどのようになるかは、下のスクリーンショットで確認できます。
図 6 - ユーザー名前空間を介した CVE-2022-0492 によるコンテナエスケープの悪用。
新しいユーザー名前空間と cgroup 名前空間を作成する代わりに、コンテナに CAP_SYS_ADMIN ケーパビリティが付与されている場合、より単純なエクスプロイトが可能です。CAP_SYS_ADMIN ケーパビリティを持つコンテナは、cgroupfs のマウントを無条件に許可されます。さらに、今日のほとんどのコンテナは cgroup 名前空間なしで実行されるため、マウントされる cgroup はルート cgroup と release_agent ファイルになります。
図 7 - 初期 cgroup 名前空間では、コンテナの cgroup に関係なく、cgroupfs をマウントすると常にルート cgroup がマウントされます。
CAP_SYS_ADMIN ケーパビリティがあっても、AppArmor と SELinux はマウントを防ぐため、いずれかを有効にして実行されているコンテナは CVE-2022-0492 を悪用できません。図 8 は、AppArmor と SELinux なしで、CAP_SYS_ADMIN ケーパビリティ付きで実行され、CVE-2022-0492 を悪用して脱出するコンテナを示しています。
図 8 - CAP_SYS_ADMIN ケーパビリティを介した CVE-2022-0492 によるコンテナエスケープの悪用。
CVE-2022-0492 は、コンテナエスケープに悪用される可能性のある、もう1つの Linux 脆弱性です。幸い、ベストプラクティスに従っている環境はこの脆弱性から保護されています。セキュリティ対策が緩い環境で信頼できないコンテナや公開されたコンテナをホストしている場合は、当然ながらリスクが高くなります。常にそうであるように、ホストを修正済みのカーネルバージョンにアップグレードすることをお勧めします。
この脆弱性や将来の Linux ゼロデイ脆弱性 から保護するために、コンテナを Seccomp と AppArmor または SELinux のいずれかを有効にして実行することを強くお勧めします。Linux カーネルにおける多くの特権昇格の脆弱性は、コンテナが新しいユーザー名前空間の作成を許可されている場合、つまりコンテナが Seccomp なしで実行されている場合にのみ、コンテナエスケープに悪用される可能性があります。
© 2022 - Not Sofiane Hamlaooui - 世界をより良い場所にする 🌎
