conda/infrastructure CIで任意コード実行の恐れ、修正済み
conda の開発用リポジトリで使われる GitHub Actions のワークフロー update.yml に、外部から送られた Pull Request の内容が、強い権限を持つトークン付きで処理されてしまう欠陥がありました。コミット 9c0f238 で修正済みです。同じ仕組みを自組織のリポジトリで使っている場合は、ワークフローの有無を確認し、修正を取り込んでください。
急ぎ度: 早めに
CVSSは9.9と最高クラスですが、実際の攻撃で悪用されたという情報は公表されておらず、影響は該当ワークフローを使うリポジトリに限られ、修正も公開済みです。
関係があるか
conda組織のリポジトリ（説明ではconda/conda）の保守に関わる人、および同じ update.yml や外部アクション conda/actions/template-files を自分のGitHubリポジトリで使っている組織が対象です。説明されているのはGitHub Actionsのワークフローの問題で、condaコマンドを使う側の実行環境への影響は記載されていません。
| 製品 | 影響を受ける版 | 直った版 |
|---|---|---|
| conda/infrastructure(conda ecosystem の infrastructure) | コミット9c0f238より前。説明ではconda/condaの .github/workflows/update.yml に問題が残っているとされています。 |
コミット9c0f238(9c0f23857282ff5cf7a6b3ad6bf0dd6f9974be55)で修正済み。リリース番号での案内は公表されていません。 |
| conda/actions/template-files(コミット 7f6830b1428a9bd47f0b068892c77eae95207037 を参照している構成) | update.yml から呼び出され、チェックアウトした作業ディレクトリのテンプレートを読み込む使い方。 |
修正はワークフロー側のコミット9c0f238で行われたと説明されています。詳細は下記の公式告知で確認してください。 |
確かめ方
- 1自組織のリポジトリで
.github/workflows/以下にupdate.ymlがあるか、issue_commentで動くワークフローがあるかを確認します。 - 2ワークフロー内に
conda/actions/template-filesの参照があるか、コメント中の@conda-bot renderや@conda-bot recreateで動く処理があるかを調べます。 - 3Pull Requestの取得元リポジトリやブランチをチェックアウトする際に、
SYNC_TOKENのような権限の強いトークンを使っていないかを確認します。 - 4conda/infrastructureから設定を取り込んで運用している場合は、取り込み済みの内容にコミット9c0f238が含まれているかを確認します。
何が起きたか
GitHub Actionsは、リポジトリで起きた出来事をきっかけに自動で処理を動かす仕組みです。今回問題になったのは、コメントに特定の指示文が書かれると動くワークフローです。この処理が、外部の人が作ったPull Requestの中身を、権限の強いトークン付きで取り込んで処理していました。そのため、外部から持ち込まれた内容が、本来は保守担当者しか使えない権限の下で実行される恐れがありました。
説明によると、問題のワークフローは .github/workflows/update.yml です。コメントに @conda-bot render または @conda-bot recreate が含まれると動きます。renderの経路では、Pull Requestの取得元リポジトリとブランチをAPIから調べ、secrets.SYNC_TOKEN を使ってそこをチェックアウトします。その後、外部アクション conda/actions/template-files を実行します。
このアクションは、設定とテンプレートをチェックアウトした作業ディレクトリから読み込みます。確認された問題では、アクションがJinja2をサンドボックスなしで使い、攻撃者が用意したテンプレートの内容を描画していました。サンドボックスのないテンプレートエンジンは、書かれた内容によって任意の処理を実行できる場合があり、分類はCWE-94（コードインジェクション）です。修正はコミット9c0f238で公開されています。
攻撃の流れ
-
1
細工したPR
攻撃者が、テンプレートの内容を書き換えたPull Requestを自分のリポジトリから送ります。
-
2
コメントで起動
指示文を含むコメントが投稿され、`update.yml` が動き始めます。
-
3
PR側を取得
ワークフローがPRの取得元を調べ、`SYNC_TOKEN` を使ってその内容をチェックアウトします。
-
4
テンプレート描画
外部アクションが、取得した作業ディレクトリのテンプレートをサンドボックスなしで描画します。
-
5
権限下で実行
外部由来の内容が、トークンを扱えるジョブの中で実行される恐れがあります。
どう悪用されるか
CVSSのベクトルでは、ネットワーク経由で攻撃でき（AV:N）、特別な条件は不要（AC:L）、利用者の操作も不要（UI:N）とされています。必要な権限は低い（PR:L）ため、Pull Requestやコメントを投稿できるGitHubアカウントがあれば足りる可能性があります。コメント投稿に追加の資格が必要かどうかは、公表内容からは分かりません。
悪用された場合、ワークフローの実行環境で攻撃者の指定した処理が動き、SYNC_TOKEN に与えられた権限の範囲で、リポジトリの読み取りや書き換えが行われる恐れがあります。評価では機密性と完全性への影響が高（C:H、I:H）、影響範囲が変わる（S:C）とされています。トークンがどこまで書き込めるかで被害の大きさが決まるため、実際の影響は各組織の設定次第です。
実際の攻撃で悪用されたという情報や、悪用される見込みを示す指標は、現時点で公表されていません。
今すぐやること
-
1
該当ワークフローの有無を確認する
自組織のリポジトリで、
update.ymlやconda/actions/template-filesを使う設定、コメントで動く処理がないかを探します。grep -rn "conda/actions/template-files" .github/workflows -
2
修正コミットを取り込む
conda/infrastructure由来の設定を使っている場合は、コミット9c0f238の変更を自分のリポジトリに反映します。内容は公式のコミットページで確認できます。
-
3
トークンの権限を見直す
SYNC_TOKENに相当するトークンが、書き込みなど必要以上の権限を持っていないか確認します。外部のPull Requestの内容を処理するジョブには、強い権限のトークンを渡さない構成にします。 -
4
実行履歴を点検する
Actionsの実行履歴で、見覚えのないアカウントのコメントやPull Requestをきっかけに動いた実行がないかを確認します。不審な実行があれば、トークンの再発行と、リポジトリへの意図しない変更の有無の確認を行います。
すぐ更新できないとき
修正をすぐ取り込めない場合は、公式の回避策は公表されていませんが、一般的な対策として update.yml を一時的に無効化するか、issue_comment で動く部分を止める方法があります。あわせて、外部由来のブランチをチェックアウトするジョブに強い権限のトークンを使わないようにしてください。
背景
今回のような問題は、GitHub Actionsの分野で「Pwn Request」と呼ばれる型です。外部の人が出したPull Requestの内容を、書き込み権限やシークレットを扱えるワークフローが処理してしまうと、外部の人が作った内容が保守者と同じ権限で動いてしまいます。コメントやPull Requestをきっかけに動くワークフローでは、信頼できない入力をどこまで処理に使うかの設計が重要になり、同じ型の指摘はGitHub Actionsを使う多くのプロジェクトで繰り返し報告されてきました。
CIのトークンは、ソースコードの変更やリリース作業に使われることが多く、社内ではビルドや配布を支える土台にあたります。そこを経由して不正な変更が入ると、成果物を使う側にも影響が及び得るため、CIの設定は製品本体と同じく点検の対象になります。
よくある質問
Q.condaを使っているだけの利用者も対応が必要ですか。
Q.すでに悪用されていますか。
Q.どの版に上げればよいですか。
まだ分かっていないこと
-
実際に攻撃が行われたか、
SYNC_TOKENが悪用された事例があるかは公表されていません。 - コメントで処理を起動するために、投稿者にどの程度の権限が必要かは、説明からは分かりません。
- conda組織以外で同じ構成を使っているリポジトリがどれだけあるかは、明らかになっていません。
この記事は、取得元の公開情報をもとに生成 AI で作成しています。誤りを含むことがあります。対応を決める前に、下の原文と参照先を確認してください。
影響パッケージ
| 種類 | パッケージ | 影響を受ける版 | 直った版 |
|---|---|---|---|
| conda | infrastructure | — | — |
原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。
Conda Organization Infrastructure is a centralized location for infrastructure codes. Prior to commit 9c0f238, a GitHub Actions Pwn Request vulnerability appears to remain present in conda/conda. The affected workflow is .github/workflows/update.yml. It is triggered by issue_comment events containing @conda-bot render or @conda-bot recreate. For the render path, the workflow obtains the pull request head repository and branch from the PR API, checks out that PR-controlled repository/ref using secrets.SYNC_TOKEN, and then runs conda/actions/template-files@7f6830b1428a9bd47f0b068892c77eae95207037. The external template-files action reads its default configuration and templates from the checked-out working directory. In the confirmed finding, that action uses an unsandboxed Jinja2 environment to render attacker-controlled template content. This creates a Pwn Request chain in which an untrusted PR/comment path can reach template rendering in a privileged token context. This issue has been patched via commit 9c0f238.
出典: CVE.org (CVE Program・cvelistV5) NVD GitHub Advisory
参照URL
- advisory github.com
- advisory github.com
- advisory nvd.nist.gov
- patch github.com