Project Zeroは、GitHubで重大なセキュリティ違反の詳細をリリースしました そして彼らはそれを報告します エラーはアクションワークフローコマンドに影響します GitHubからのものであり、重大度が高いと説明されています。 （このバグは90月に発見されましたが、標準のXNUMX日間の開示期間では、詳細は現在リリースされているだけです。）
この欠陥は、修正されなかった数少ない脆弱性のXNUMXつになりました Google ProjectZeroによって付与された標準の90日の期間が満了する前に適切に。
フェリックスウィルヘルムによると （誰がそれを発見したか）、Project Zeroチームのメンバーであるこの欠陥は、開発者の作業を自動化するツールであるGitHubアクション機能に影響を与えます。 これは、アクションワークフローコマンドが「インジェクション攻撃に対して脆弱」であるためです。
「アクションGithubは、アクションブローカーと実行されたアクション間の通信チャネルとしてワークフローコマンドと呼ばれる機能をサポートしています。 ワークフローコマンドは/ src / Runner.Worker / ActionCommandManager.csに実装されており、XNUMXつのコマンドマーカーのいずれかを探すことによって実行されるすべてのアクションのSTDOUTを解析することによって機能します。
言及する この機能の大きな問題は、注入攻撃に対して非常に脆弱であるということです。 実行プロセスはSTDOUTに出力されたすべての行をスキャンしてワークフローコマンドを探すため、実行の一部として信頼できないコンテンツを含むすべてのGitHubアクションは脆弱です。
ほとんどの場合、任意の環境変数を設定する機能により、別のワークフローが実行されるとすぐにリモートコードが実行されます。 私は人気のあるGitHubリポジトリを調べてきましたが、少し複雑なGitHubアクションを使用するほとんどすべてのプロジェクトは、この種のバグに対して脆弱です。
続いて バグを悪用する方法の例をいくつか挙げました また、解決策を提案しました：
「私はそれを修正するための最良の方法が本当にわかりません。 ワークフローコマンドの実装方法は根本的に安全ではないと思います。 v1コマンド構文を減価償却し、許可リストを使用してet-envを強化すると、直接RCEベクトルに対して機能する可能性があります。
「しかし、後のステップで使用される「通常の」環境変数をオーバーライドする機能でさえ、より複雑なアクションを活用するにはおそらく十分です。 また、ワークスペース内の他のコントロールのセキュリティへの影響を分析していません。
さらに、良い長期的な解決策に言及する STDOUTによる解析を回避するために、ワークフローコマンドを別のチャネル（新しいファイル記述子など）に移動することですが、これにより、既存のアクションコードの多くが破損します。
GitHubに関しては、開発者は1月2020日にアドバイザリを投稿し、脆弱なコマンドを非推奨にしましたが、Wilhelmが見つけたのは実際には「中程度のセキュリティの脆弱性」であると主張しました。 GitHubはバグ識別子CVE-15228-XNUMXを割り当てました：
「GitHubActionsランタイムで中程度のセキュリティの脆弱性が確認されました。これにより、信頼できないデータをSTDOUTに記録するワークフローにパスと環境変数を挿入できる可能性があります。 これにより、ワークフローの作成者の意図なしに環境変数が導入または変更される可能性があります。
「この問題を解決し、環境変数を動的に設定できるようにするために、ワークフローで環境とパスの更新を処理するための新しいファイルセットを導入しました。
「セルフホストブローカーを使用している場合は、バージョン2.273.1以降に更新されていることを確認してください。
Wilhelmによると、12月14日、Project ZeroはGitHubに連絡し、GitHubが脆弱なコマンドを無効にするためにより多くの時間を必要とする場合、19日間のウィンドウを積極的に提供しました。 もちろん、オファーは受け入れられ、GitHubは2月XNUMX日以降に脆弱なコマンドを無効にすることを望んでいました。 その後、プロジェクトゼロはXNUMX月XNUMX日の新しい開示日を設定しました。