distributed-workloadsのCI脆弱性、修正済み
Red Hatが管理するGitHubリポジトリのワークフローに、CI用の秘密情報を外部へ持ち出される脆弱性がありましたが、ワークフローの削除で対処済みです。利用者が更新を当てる話ではなく、自社のGitHub Actionsに同じ構成がないかを点検してください。
急ぎ度: 計画的に
CVSS v3は9.1ですが、Red Hatは影響度をModerateとし、問題のワークフローは削除済みで、利用者側で当てる更新もないためです。
関係があるか
影響を受けたのはRed Hat側のGitHubリポジトリで、OpenShift AIを使うだけの組織が直接被害を受ける話ではありません。実際に点検が要るのは、自社のリポジトリで同じ種類のワークフローを動かしている組織です。
| 製品 | 影響を受ける版 | 修正版 |
|---|---|---|
| red-hat-data-services/distributed-workloads リポジトリ（Red Hat OpenShift AI（RHOAI）に関わる） | 版の指定はありません。問題はリポジトリ内のpull_request_targetワークフローにありました。 | 版を上げる形の修正版はなく、Red Hatがワークフローを削除し、SNYK_TOKENを取り除いて対処しています。 |
確かめ方
- 1OpenShift AIを使っている場合は、Red HatのCVE情報と、そこから参照されているBugzillaの記録で、自社の製品や版への影響の有無を確認します。
- 2自社のリポジトリの
.github/workflowsで、pull_request_targetを使うワークフローを洗い出します。 - 3見つかったワークフローが、プルリクエスト作成者のコードを取得・実行していないか、シークレットや書き込み権限のあるトークンを参照していないかを読んで確認します。
- 4外部のアクションを、タグやブランチ名（@masterなど）で参照していないかも見ます。
何が起きたか
Red Hat OpenShift AIに関わるGitHubリポジトリで、外部から送られた変更提案（プルリクエスト）をきっかけに、CI用の秘密情報が持ち出されるおそれがありました。
問題があったのは、red-hat-data-services/distributed-workloadsリポジトリのpull_request_targetワークフローです。このワークフローは、プルリクエスト作成者のコードという信頼できない入力を扱いながら、元のリポジトリが持つSNYK_TOKENなどのシークレットと、標準で付く書き込み用トークンが使える状態で動いていました。CWEはCWE-829です。
もう一つの背景として、アクションをタグやブランチ名で参照していました。サードパーティのsnyk/actions/setup@masterも含まれており、参照先が後から書き換わりうる構成でした。
悪用されると、Snyk連携への不正なアクセスや、リポジトリの制御を奪われるおそれがありました。Red Hatは、問題のワークフローの削除とSNYK_TOKENの除去で対処済みとしています。
攻撃の流れ
-
1
細工したPRを送付
攻撃者が、悪意のある内容を含むプルリクエストをリポジトリに送ります。
-
2
ワークフローが起動
pull_request_targetのワークフローが、作成者のコードを扱いながら元リポジトリの権限で動きます。
-
3
秘密情報の持ち出し
SNYK_TOKENや書き込み用トークンが外部へ送られます。
-
4
不正アクセス
Snyk連携への不正アクセスや、リポジトリの制御を奪われるおそれが生じます。
どう悪用されるか
CVSSのベクトルでは、ネットワーク経由で、攻撃の複雑さは低く、事前の権限も利用者の操作も要らないとされています。攻撃者がやることは、細工したプルリクエストを送ることです。
被害は、機密性と完全性への高い影響として評価されています。持ち出されるのはSNYK_TOKENのようなシークレットと書き込み用トークンで、可用性への影響はありません。Red Hat自身の評価はModerateで、NVD側のCVSS v3 9.1より低くなっています。
今すぐやること
-
1
Red Hatの情報で自社の利用状況を確認する
OpenShift AIを使っている場合は、Red HatのCVE情報とBugzillaの記録で、製品への影響の有無を確認します。リポジトリ側で対処済みなので、利用者が更新を当てる必要は示されていません。
-
2
自社のワークフローを点検する
pull_request_targetを使うファイルを洗い出し、プルリクエストのコードを扱う処理と、シークレットを使う処理が同じジョブにないかを確認します。
grep -rn "pull_request_target" .github/workflows -
3
構成を見直す
外部のコードを扱うジョブにはシークレットを渡さず、トークンの権限は必要最小限にします。外部アクションはタグやブランチ名ではなく、コミットのSHAで固定します。
-
4
疑わしい場合はシークレットを入れ替える
同じ構成で外部からのプルリクエストを受けていた場合は、関係するトークンを再発行し、実行履歴に不審な点がないかを確認します。
すぐ更新できないとき
本件についてRed Hatは、回避策は提供されていないとしています。自社のリポジトリで同じ構成が見つかり、すぐに直せない場合のつなぎとしては、該当ワークフローを一時的に無効化し、関係するシークレットを再発行します。
背景
pull_request_targetは、プルリクエストの作成元ではなく、元のリポジトリの権限とシークレットで動くGitHub Actionsのトリガーです。ラベル付けやコメント投稿のような処理に向く一方、作成者のコードを取得して実行すると、外部の人が書いたコードにシークレットを渡すのと同じ状態になります。CWE-829が示す「管理の外にある機能の取り込み」は、この構成の典型的な落とし穴です。
今回のリポジトリでは、Snyk連携用のSNYK_TOKENがこの経路にありました。Snykは依存パッケージなどの脆弱性を調べるサービスで、そのトークンはCIから呼び出す認証情報にあたります。さらにアクションを@masterのような可変の参照で呼んでいたため、参照先が書き換わった場合の影響も同じ記録で指摘されています。
よくある質問
Q.CVSSは9.1なのに、なぜRed HatはModerateと評価しているのですか。
Q.Snykを使っている自社のトークンも危ないのでしょうか。
まだ分かっていないこと
- 実際に悪用されたか、秘密情報が外部へ持ち出されたかは公表されていません。
- 影響を受けた版と修正版の版番号は示されていません。
この記事は、取得元の公開情報をもとに、人が監修しながらAIを活用して執筆しています。執筆と監修は佐々木 航が担い、公開したあとも人が内容を確認しています。誤りに気づいたときは直し、記事の末尾に訂正の行を残します。対応を決める前に、下の原文と参照先も確認してください。
原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。
A flaw was found in distributed-workloads. A remote attacker could exploit a vulnerability in the pull_request_target workflow by submitting a specially crafted pull request. This workflow processes untrusted code from the pull request author while operating with the base repository's sensitive secrets, such as the SNYK_TOKEN, and its default write token. Consequently, an attacker could exfiltrate these secrets, leading to unauthorized access to the Snyk integration and potential control over the repository.
出典: CVE.org (CVE Program・cvelistV5) NVD GitHub Advisory
参照URL
- web secalert@redhat.com
- web secalert@redhat.com
- web nvd.nist.gov
- web github.com