GH Actions - Cache Poisoning
詳細については、元の投稿を確認してください https://scribesecurity.com/blog/github-cache-poisoning/
Cache Poisoning
Gitアクション action/cache は、継続的インテグレーション（CI）プロセスにキャッシングメカニズムを導入し、2つの重要なステージを含みます：
アクションの実行: このステージでは、CI実行中にキャッシュデータを検索して取得します。検索はユニークなキャッシュキーを利用し、2つの結果をもたらします：
キャッシュヒット: リクエストされたデータがキャッシュ内に見つかり、即座に使用のために取得されます。
キャッシュミス: キャッシュ内に一致するデータが見つからず、必要なファイルとディレクトリを新たにダウンロードする必要があります。これは初回リクエストに似ています。
ワークフロー後のアクション: このステージは、CIワークフロー後にデータをキャッシュすることに専念しています。具体的には、実行アクション中にキャッシュミスが発生した場合、指定されたディレクトリの現在の状態が提供されたキーを使用してキャッシュされます。このプロセスは自動化されており、明示的な呼び出しは必要ありません。
セキュリティ対策: キャッシュの分離とアクセス制限
セキュリティを維持し、キャッシュの分離を確保するために、アクセス制限が施され、異なるブランチ間に論理的な分離が作成されます。たとえば、ブランチ Feature-A（メインブランチを基にしている）のために作成されたキャッシュは、ブランチ Feature-B（同じくメインブランチを基にしている）のプルリクエストにはアクセスできません。
キャッシュアクションは特定の検索順序に従います：
最初に、ワークフロー実行と同じブランチ内でキャッシュヒットを探します。
失敗した場合、親ブランチや他の上流ブランチに検索を拡張します。
重要なことに、キャッシュアクセスはブランチスコープであり、特定のブランチのすべてのワークフローと実行にわたって拡張されます。さらに、GitHubはキャッシュエントリが作成されると、読み取り専用ポリシーを強制し、変更を禁止します。
実世界の影響: 低権限ワークフローから高権限ワークフローへの攻撃
具体的なCIシナリオは、攻撃者がキャッシュポイズニングを利用して低権限ワークフローから高権限ワークフローに権限を昇格させる方法を示しています：
Unit-test ワークフローは、ユニットテストとコードカバレッジツールを実行する責任があり、妥協されたまたは脆弱なツールを使用していると仮定します。このワークフローは action/cache Gitアクションを利用しており、キャッシュは任意のワークフローにアクセス可能です。
Release ワークフローは、アプリケーションアーティファクトをビルドしてリリースする責任があり、Golang依存関係をキャッシュすることで操作を最適化します。
このシナリオでは、ユニットテストワークフローが正当なGolangロギングライブラリを置き換えることによって悪意のあるキャッシュエントリを導入します。
Last updated
