Linux カーネルのバグが Kubernetes コンテナからの脱出を許す?

Linux kernel bug can let hackers escape Kubernetes containers

2022/01/25 BleepingComputer — Linux カーネルに影響する脆弱性 CVE-2022-0185 が、Kubernetes のコンテナを脱出する攻撃者に利用されると、ホストシステム上のリソースへのアクセスを許すことになる。セキュリティ研究者たちは、この欠陥の悪用は当初の予測よりも容易であり、間もなくエクスプロイト・コードが公開されるため、パッチの適用が急務であると警告している。

コンテナ・ブレイクアウトは、サイバー攻撃の中では特殊なものであり、侵入されたネットワークの深部への侵入を許し、横方向に移動する道を開くことになる。

限定的ではない脆弱性

脆弱性 CVE-2022-0185 は、Linux カーネルの File System Context コンポーネントに存在する、ヒープバッファ・オーバーフローの欠陥であり、境界外書き込み/サービス拒否/任意のコード実行などにつながる可能性がある。このフローが発生すると、攻撃者によるはカーネル・メモリ内の値の変更や、同じノードで実行されている任意のプロセスへのアクセスが生じる可能性がある。

先週に、Linux ディストリビューターたちが発したセキュリティ通知によると、この欠陥は、特権を拡大したローカル・ユーザーに悪用される可能性があるという。しかし、この悪用プロセスを攻撃者が成功させるには、非特権の名前空間の活用もしくは、unshare を使用して CAP_SYS_ADMIN 権限を持つ名前空間に入る必要がある。

この能力は Docker のデフォルト設定ではなく、コンテナの起動時に -privileged フラグを使用することも一般的ではない。さらに、unshare コマンドは、Dockerの seccomp フィルタによりデフォルトでブロックされているため、そのコマンドの実行が許可されていない。

ただし、Aquasec のアナリストによると、Docker などののコンテナ・プラットフォームを Kubernetes クラスタで使用している場合は、デフォルトで seccomp フィルタが無効になっているため、unshare コマンドはブロックされないという。そのため、このコマンドを攻撃者が実行すると、完全な機能を持つシェルが取得され、侵害されたシステム上での root としてのコード実行などを許すことになる。

この脆弱性を発見したのは、Crusaders of Rust (CoR) の CTF チーム・メンバーである William Liu と Jamie Hill-Daniel だ。このチームには、ヨーロッパとアメリカから、合計で 21名のメンバーが参加している。

BleepingComputer の取材に対して CoR のメンバーは、パッチ適用のための時間を確保するために、CVE-2022-0185 のエクスプロイト・コードを、1週間ほど待って公開する予定だと述べている。なお、このコードは、CoR の GitHub リポジトリで公開されることになる。

このヒープオーバーフローのバグは、5.1-rc1 から最新のパッチを適用したもの (5.4.173/5.10.93/5.15.1) までの、すべての Linux カーネル・バージョンに影響する。また、この脆弱性は、Ubuntu 20/21/Debian 11/Red Hat の一部パッケージにも影響する。

この脆弱性に対するエクスプロイト・コードが作成されており、この脆弱性の悪用も実証されていると、発見した研究者の一人が述べている。また、CoR チームは、Docker コンテナ用に最適化された OS である、Google Container に対するエクスプロイト・コードも作成しているとのことだ。

対策

Linux カーネルを Ver 5.16.2 以降にアップグレードすることで、この問題に対処できる。ただし、このアップデートは、すべての Linux ディストリビューションで利用できるわけではなく、カーネルをソースからビルドするという選択肢は、多くのシステム管理者に受け入れられていない。

このような場合は、非特権ユーザーの名前空間を無効にして、CAP_SYS_ADMIN を持つポッドを絶対に必要なワークロードにのみ置いておくことが推奨される。
Ubuntuでは、以下のコマンドを使用して、非特権ユーザーの名前空間を無効にしている。

sysctl -w kernel.unprivileged_userns_clone=0

コンテナ化されたデプロイメントを必要としない Red Ha tユーザーは、以下のコマンドでユーザーネーム・スペースを無効にできる。

echo “user.max_user_namespaces=0” > /etc/sysctl.d/userns.confsysctl -p /etc/sysctl.d/userns.conf

非特権コンテナが必要な場合には、seccomp フィルターが unshare コールを積極的にブロックしていることを確認する。個々のワークロードでは、seccomp を securityContext フィールドの定義として追加することが可能だ。Kubernetes には、その方法についての詳細なチュートリアルが存在するので、ぜひチェックしてほしい

これまでに、このブログに Kubernetes が登場したのは、2021年5月の「約5万件の脆弱な IP アドレスが TeamTNT により Kubernetes クラスターに」と、2021年7月の「NSA : Russian GRU ハッカーたちは Kubernetes を悪用してブルートフォースを仕掛ける」です。また、関連するトピックとしては、2021年9月の「Microsoft Azure クロス・アカウント・コンテナ乗っ取りの脆弱性が FIX」がありました。文中でも、「コンテナ・ブレイクアウトは、サイバー攻撃の中では特殊なものであり、侵入されたネットワークの深部への侵入を許し、横方向に移動する道を開くことになる」と指摘されていますが、新たな TTP として定着していくのでしょうか?

%d bloggers like this: