Beta9 workerのビルド隔離を破られる脆弱性、修正版あり
Beta9のビルド用workerで、テナントが画像ビルドを1回依頼するだけでworkerのコンテナ側に出られる脆弱性が公表されました。複数のテナントにBeta9を使わせている環境は、worker 0.1.756へ更新し、ビルド権限の範囲も見直してください。
急ぎ度: 至急
CVSS v3は9.9で、workspace tokenを持つテナントなら1回のビルド依頼で到達でき、公表と同日に修正版worker 0.1.756が出ています。
関係があるか
Beta9を自前のKubernetesクラスターで動かし、社内の複数部門や社外の顧客など、信頼度の異なる利用者にイメージビルドを許している環境が主な対象です。利用者が自分たちだけの単一テナント運用でも、版が古ければ該当します。
| 製品 | 影響を受ける版 | 修正版 |
|---|---|---|
| Beta9 worker（beam-cloud） | 0.1.756未満 | 0.1.756 |
確かめ方
- 1Beta9のworkerを動かしているPodのイメージタグを確認し、0.1.756未満でないかを調べます。
- 2workerイメージを独自に再ビルドしている場合は、ベースにした版と、修正を含むコミットを取り込んだかを確認します。
- 3Beta9をBeam側のマネージドサービスで使っている場合は、ベンダーの告知で影響の有無と対応状況を確認してください。
何が起きたか
Beta9のビルド用workerに、イメージビルドの隔離が不十分な脆弱性が見つかりました。テナントが定義したイメージのビルド手順が、workerのコンテナから十分に切り離されないまま実行されます。その結果、ビルド中の処理がworkerコンテナの中身に触れられます。
Beta9はテナントのイメージ定義にある各シェルコマンドをDockerfileのRUN行に変換し、workerでBuildahを使って実行します。ところがworkerのイメージはBUILDAH_ISOLATION=chrootを指定していて、Buildahの呼び出しに--isolationも付いていません。そのため各ステップは、見えるファイルシステムの根を切り替えるだけです。PID・ネットワーク・IPC・ユーザーの名前空間はworker Podと共有され、処理はuid 0で動き、CAP_DAC_OVERRIDEも持っています。
workerコンテナのファイルシステムには、テナントのコンテナを起動するruncやbuildah、runscの実行ファイルがあります。ほかに、workerのKubernetesサービスアカウントトークンと、Podにマウントされたホストのディレクトリもあります。worker Podは特権で動いているため、影響はビルド環境にとどまらない構造です。報告者は読み取りのみの検証で、名前空間の共有、CAP_DAC_OVERRIDE、workerのruncが見えることを確認しています。
修正版のworker 0.1.756は、BuildahのRUNステップ（WORKDIRのmkdirを含む）をOCI隔離で実行します。PID・IPC・ネットワークの名前空間はステップごとに分けられ、テナントが渡すARGの値もビルド用コンテナの中にだけ渡されます。
攻撃の流れ
-
1
ビルドを依頼
workspace tokenを持つテナントが、細工したイメージ定義でビルドを1回依頼します。
-
2
workerで実行
ビルド手順がchrootだけの隔離で、worker Podの名前空間を共有したまま実行されます。
-
3
workerの中身に到達
ビルド中の処理が、workerコンテナのファイルシステムを読み書きできる位置に出ます。
-
4
資格情報と実行ファイル
サービスアカウントトークン、コンテナ起動用の実行ファイル、マウントされたホストのディレクトリに手が届きます。
-
5
クラスター全体へ
特権Podであるため、ほかのテナントやクラスターへ被害が広がるおそれがあります。
どう悪用されるか
必要なのは、テナントに発行されるworkspace tokenだけです。ネットワーク経由で、特別な条件や別の利用者の操作は要りません。Clip v2のレイヤー型ビルドが既定なので、有効な利用者が1回イメージビルドを依頼すれば到達できます。CVSSの評価でも、権限は低、利用者の操作は不要、影響範囲は変わる（S:C）とされています。
悪用に成功すると、テナント用のビルド環境を出て、workerコンテナ側の情報や実行ファイルに触れられます。サービスアカウントトークンが読まれればKubernetes APIへの足がかりになり、コンテナ起動に使う実行ファイルが書き換えられれば、ほかのテナントのワークロードにも影響します。機密性・完全性・可用性のすべてが高と評価されているのはこのためです。
今すぐやること
-
1
workerを0.1.756に更新する
ビルド用workerのイメージを修正版に差し替え、Podを入れ替えます。更新後に、動いているPodが新しいイメージになっているかを必ず確認してください。
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{range .spec.containers[*]}{.image}{" "}{end}{"\n"}{end}' | grep -i worker -
2
ビルドを依頼できる利用者を洗い出す
workspace tokenが発行されている範囲を一覧にし、不要なトークンを失効させます。更新が済むまでは、信頼できないテナントのビルド依頼を止めるかどうかも検討します。
-
3
ビルド履歴に不審な点がないか調べる
公表前から未更新の期間があるなら、見覚えのないテナントや、普段と違う手順を含むイメージ定義のビルドが走っていないかを確認します。
-
4
資格情報の扱いを見直す
不審なビルドが見つかった場合は、workerのサービスアカウントトークンを入れ替え、そのアカウントの権限と、Kubernetes APIの監査ログも確認します。
-
5
ベンダーの告知を確認する
Beta9のリポジトリにあるリリースノートで、修正の範囲と更新手順を読み、自社の構成に追加の作業がないかを確認します。
すぐ更新できないとき
修正版を当てられない間は、ビルドを依頼できる利用者を信頼できる範囲に絞るのが現実的なつなぎです。workspace tokenを棚卸しして不要なものを失効させ、必要ならビルド機能自体を一時的に止めます。ただし根本の解決にはならないので、更新は早めに済ませてください。
背景
Beta9は、コンテナ化したワークロードを自前のクラスターで動かすためのオープンソースの実行基盤で、テナントごとにイメージを定義してビルドできます。ビルドを受け持つworkerは、利用者が書いた任意のシェルコマンドを実行する場所です。同時に、テナントのコンテナを起動する実行ファイルや、Kubernetesの資格情報も抱えています。信頼できないコードを動かす場所と、基盤の鍵が置かれた場所が同じworkerにあるため、境界の強さがそのまま基盤全体の安全性になります。
chrootはプロセスから見えるファイルシステムの根を切り替えるだけで、PIDやネットワークなどの名前空間、権限は分けません。セキュリティ上の境界としては不十分だとよく知られています。今回の脆弱性は、まさにこの点にあります。修正版では、ビルドの各ステップをOCI隔離で動かすようにして、名前空間を分けました。
よくある質問
Q.社内の信頼できる人しかビルドを依頼しない環境でも、更新は必要ですか。
Q.更新したあとに、ほかに入れ替えるものはありますか。
この記事は、取得元の公開情報をもとに、人が監修しながらAIを活用して執筆しています。執筆と監修は佐々木 航が担い、公開したあとも人が内容を確認しています。誤りに気づいたときは直し、記事の末尾に訂正の行を残します。対応を決める前に、下の原文と参照先も確認してください。
影響パッケージ
| 種類 | パッケージ | 影響を受ける版 | 修正版 |
|---|---|---|---|
| beam-cloud | Beta9 worker |
0.1.756 未満 |
0.1.756 |
原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。
Beta9 turns each shell command in a tenant image definition into a Dockerfile RUN line and executes it with Buildah on the build worker. The worker image sets BUILDAH_ISOLATION=chroot, and no buildah invocation passes --isolation, so the step only changes its filesystem root. It keeps the worker pod's PID, network, IPC, and user namespaces, runs as uid 0, and holds CAP_DAC_OVERRIDE. PID 1 in that procfs is the worker entrypoint, so /proc/1/root is the worker container's filesystem and is writable. That filesystem contains the runc, buildah, and runsc binaries the worker uses to start tenant containers, the worker's Kubernetes service account token, and the host directories mounted into the pod. Worker pods are privileged. Clip v2 layered builds are the default, so a tenant with a workspace token reaches this by submitting one image build. The read-only proof confirmed the shared namespaces, CAP_DAC_OVERRIDE, and that the worker's runc binary is visible at /proc/1/root. Fixed in worker 0.1.756: Buildah RUN steps, including the WORKDIR mkdir, use OCI isolation with private PID, IPC, and network namespaces, and tenant ARG values are passed only into the build container.
出典: CVE.org (CVE Program・cvelistV5) NVD GitHub Advisory
参照URL
- advisory github.com
- advisory nvd.nist.gov
- advisory github.com
- package github.com
- package github.com
- package github.com
- patch github.com
- patch github.com
- web github.com