CVE-2022-0185:Kubernetesのコンテナエスケープを可能にするLinux Kernelの脆弱性 #aqua #セキュリティ #k8s #linux #kernel #脆弱性 #CVE20220185
この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。
本ブログは「Aqua Security」社の技術ブログで2022年1月24日に公開された「 CVE-2022-0185 in Linux Kernel Can Allow Container Escape in Kubernetes 」の日本語翻訳です。
CVE-2022-0185:Kubernetesのコンテナエスケープを可能にするLinux Kernelの脆弱性
先日 Linux カーネルに影響を及ぼす、深刻度の高い新たな CVE が発表されました。この脆弱性は、非特権ユーザとしてシステムにアクセスした攻撃者が、その権利を root に昇格させる機会を提供するものです。これを行うには、攻撃者は特定の Linux Capability「CAP_SYS_ADMIN」を持っている必要があり、一部のケースではコンテナエスケープのリスクを軽減できます。しかし、多くの Kubernetes クラスターでは、攻撃者がこの問題を悪用する可能性があります。
現時点では、この問題に対するエクスプロイトコードは公開されていません。しかし、発見した研究者の1人が、コンテナのブレイクアウトを示す概念実証を投稿しており、近々エクスプロイトコードが公開されると予想されます。
コンテナエスケープに対するエクスプロイト性
この脆弱性を悪用して、標準的なコンテナ化された環境からエスケープすることが可能かどうかを考えるとき、次のような観点で確認することができます。
"「CAP_SYS_ADMIN」Capability に依存しますが、この権限は現在のネームスペースでのみ付与される必要があります。非特権ユーザは unshare(CLONE_NEWNS|CLONE_NEWUSER) を使用して、CAP_SYS_ADMIN Capability を持つネームスペースに入り、システムを root 化するために悪用を進めることができます。"
CAP_SYS_ADMIN Capability は、意図的に追加されるか、コンテナ起動時に -privileged フラグを使用しない限り、Docker や他のコンテナ化環境が提供する標準セットには含まれません。
ただし、本アドバイザリ情報によれば、非特権ユーザが unshare Linux コマンドを使用して新しいネームスペースに入り、本脆弱性を悪用できるCapabilityが取得できる、とも指摘しています。
標準的な Docker 環境では、unshare コマンドの使用は、Docker の seccomp フィルターによってブロックされ、このコマンドが使用するシステムコールはブロックされます。このことは、標準的な Docker コンテナを実行することで確認できます。
|
docker run -it ubuntu:20.04 /bin/bash |
このとき、Kubernetes クラスターで Docker(または他の CRI)を使用する場合、seccomp フィルターはデフォルトで無効になっているため、この脆弱性を悪用される可能性があります。Kubernetes でコンテナを実行することで、その違いを確認できます。
kubectl run -it ubutest2 --image=ubuntu:20.04 /bin/bash
コンテナを起動後、pscap コマンドによって、どのような Capability が存在するかを確認できます。
|
root@ubutest2:/# pscap -a |
この時点では、該当する Capability は存在していません。unshare コマンドを使用すると、システムコールがブロックされず、新しいシェルが全ての Capability を利用できる状態(「Full」の状態)であるとわかります。つまり、システムがこの問題に対して脆弱であるということです。
| root@ubutest2:/# unshare -r # pscap -a ppid pid name command capabilities 0 1 root bash chown, dac_override, fowner, fsetid, kill, setgid, setuid, setpcap, net_bind_service, net_raw, sys_chroot, mknod, audit_write, setfcap 1 270 root sh full |
CVE-2022-0185の緩和策
この脆弱性の危険性があるすべてのシステムは、できるだけ早くお使いの Linux ディストリビューションのパッチを適用する必要があります。このパッチのインストールには、おそらくホストの再起動が必要です。
それが難しい場合は、本脆弱性を利用したコンテナのエスケープリスクを低減するために、他のいくつかの選択肢があります。まず、組織は、CAP_SYS_ADMIN にアクセスできる特権付きコンテナの使用を最小限に抑える必要があります。
非特権コンテナについては、unshare コールをブロックする seccomp フィルターを確実に設置することで、リスクを軽減できます。このフィルターは、すべての Docker インストール時にデフォルトで設定されているはずです。しかし、Kubernetes 環境の場合は、いくつかの追加作業が必要になります。
個々のワークロードについては、ワークロード定義の securityContext フィールドに seccomp の設定ができます。
また、クラスター運用者がクラスター内のすべてのワークロードに対して、デフォルトで seccomp プロファイルを有効にできるようにすることも考えられます。ただし、これは現在アルファ版の機能であるため、オプトインのフィーチャーフラグが必要です。願わくば、この機能は Kubernetes 1.24 でベータ版となり、より広く利用できるようになることを願っています。
非特権コンテナからのエクスプロイトを軽減するもう1つのオプションは、ホストレベルでユーザのネームスペースを使用する能力を無効にすることです。これは、再起動せずにホスト上で sysctls を設定することで実現できますが、システムの運用を中断させないようにするための注意が必要です。
例えば、Ubuntu ベースのディストリビューションでは、以下のコマンドでこの機能を無効にできます。
sudo sysctl -w kernel.unprivileged_userns_clone=0
まとめ
コンテナ環境はいくつかの層で構成されているため、クラスター運用者はそれぞれの場所のセキュリティ問題に注意を払う必要があります。最終的に、ほとんどのコンテナは Linux カーネルのセキュリティに依存しているため、セキュリティ問題を迅速に解決し、クラスターの安全性を確保することが重要です。
CVE 情報：https://www.openwall.com/lists/oss-security/2022/01/18/7
