fbpx

CL LAB

HOME > CL LAB > AquaSecurity > CVE-2022-0811:CRI-Oの脆弱性により、コンテナエスケープの可能性 #aqua #セキュリティ #コンテナ #cve20220811 #crio #コンテナエスケープ #k8s

CVE-2022-0811:CRI-Oの脆弱性により、コンテナエスケープの可能性 #aqua #セキュリティ #コンテナ #cve20220811 #crio #コンテナエスケープ #k8s

 ★ 0

本ブログは「Aqua Security」社の技術ブログで2022年3月17日に公開された「 CVE-2022-0811: CRI-O Vulnerability Could Allow Container Escape 」の日本語翻訳です。

CVE-2022-0811:CRI-Oの脆弱性により、コンテナエスケープの可能性


コンテナランタイムツール「CRI-O」に新たな脆弱性が発見されました。この脆弱性により、同ソフトウェアを使用する Kubernetes や OpenShift クラスターで Pod を作成できる攻撃者は、基盤となるクラスターノードに侵入し、事実上特権に昇格できる可能性があります。この問題に対処する最善の方法は、これまでと同様に、適切なセキュリティパッチを適用することです。パッチが適用されるまでの間、この問題を悪用した攻撃を軽減するために、他にいくつかの対策を講じることができます。

技術的バックグラウンド

この問題に関するオリジナルの投稿は、どのように悪用されるかを示す再現性のある概念実証を提供しています。さらに、研究者は、この問題を利用して、脆弱なクラスターノードを完全に悪用する方法を示しています。

基本的に、この脆弱性は Kubernetes マニフェストの sysctls セクションに渡されたパラメータが、十分な検証をせずサポートユーティリティへ渡される方法に起因しています。この検証の欠如により、攻撃者はコンテナエスケープを可能にする方法で、他のシステムパラメータを変更できます。

AdmissionControllを緩和策として活用

脆弱性の記述から、この問題が引き起こされる方法は、攻撃者がマニフェストにカスタム sysctls の値を設定する必要があります。

そのため、Kubernetes レベルでの緩和策がいくつか考えられます。クラスター内で実行されているワークロードがカスタム sysctl を設定する必要がない場合、それらを設定しようとする試みをブロックすることで、悪用ベクトルをブロックできます。カスタム sysctls が必要な場合、別のアプローチ(ただし、より複雑で脆い可能性がある)として、特定のフィールドのキー文字(+と=)をブロックすることを試みることになります。

最初のオプションは、限定的または全くカスタムポリシーを記述する必要がないため、パッチの展開中に迅速な修正として実装するのが最も簡単でしょう。ただし、現在クラスターに配備されているワークロードがこの機能を使用していないことを確認するために、注意を払う必要があります。人気のあるオープンソースの AdmissionController を見ると、マニフェストのこの領域を見るポリシーが既に存在しているとわかります。

OPA の場合、gatekeeper-library リポジトリに、カスタム sysctl の設定をブロックするために使用できるテンプレートがあります。このテンプレートを適用し、すべてのカスタム sysctl をブロックする制約を作成することで、保護が可能になります。

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPForbiddenSysctls
metadata:
  name: psp-forbidden-sysctls
spec:
  match:
   kinds:
     - apiGroups: [""]
       kinds: ["Pod"]
  parameters:
   forbiddenSysctls:
   - "*"

exploit ブログに掲載されているサンプルマニフェストを適用してみると、以下のような結果が出力されます。

Kubernetes AdmissionControll のオプションとして、Kyverno もよく知られています。ポリシーライブラリを見ると、ホワイトリストに載っていない sysctl をブロックするサンプルポリシーもあることがわかります。すべての sysctl をブロックしようとするため、あまり実用的ではありませんが、これを修正するのは簡単です。パターンセクションを次のように変更するだけです。

       pattern:
         spec:
           =(securityContext):
             X(sysctls): "null"

このように、カスタムの sysctl を使用するすべてに一致させる必要があります。ブロックするためには、validationFailureAction も enforce に変更する必要があります。クラスターまたは特定の Namespace レベルに適用されたこのポリシーで、エクスプロイトマニフェストを適用しようとすると、ポリシーによってブロックされたことを示すエラーが表示されます。

まとめ


この脆弱性は、コンテナエスケープを可能にする最近のいくつかの問題のうちの1つです。他のいくつかの問題と同様に、関連するセキュリティパッチを適用するまでの間、悪用の可能性を低減するために使用できる保護手段があります。

Kubernetes や OpenShift のような複雑な環境では、多層防御し、どこで緩和策を適用できるかを理解することが重要です。これにより、セキュリティパッチの緊急展開の必要性を低減し、運用チームにシステムの運用に影響を与えないことを確認するためのテストの時間を確保することができます。

New call-to-action

CL LAB Mail Magazine

CL LABの情報を逃さずチェックしよう!

メールアドレスを登録すると記事が投稿されるとメールで通知します。

メールアドレス: 登録

※登録後メールに記載しているリンクをクリックして認証してください。

Related post

[無料ウェビナー] GitLab_CI/CDハンズオン_2023111