GH Actions - Cache Poisoning
Pour plus de détails, consultez le post original https://scribesecurity.com/blog/github-cache-poisoning/
Cache Poisoning
L'action Git action/cache introduit un mécanisme de mise en cache dans le processus d'Intégration Continue (CI), englobant deux étapes critiques :
Exécuter l'action : Cette étape consiste à rechercher et à récupérer des données mises en cache pendant l'exécution de la CI. La recherche utilise une clé de cache unique, produisant deux résultats :
Cache-hit : Les données demandées sont trouvées dans le cache et sont donc récupérées pour une utilisation immédiate.
Cache-miss : Aucune donnée correspondante n'est trouvée dans le cache, ce qui entraîne un téléchargement frais des fichiers et répertoires requis, semblable à une demande initiale.
Action Post Workflow : Cette étape est dédiée à la mise en cache des données après le workflow CI. Plus précisément, si un cache-miss se produit pendant l'action d'exécution, l'état actuel des répertoires spécifiés est mis en cache en utilisant la clé fournie. Ce processus est automatisé et ne nécessite pas d'invocation explicite.
Mesures de sécurité : Isolation du cache et restrictions d'accès
Pour maintenir la sécurité et garantir l'isolation du cache, des restrictions d'accès sont appliquées, créant une séparation logique entre les différentes branches. Par exemple, un cache créé pour la branche Feature-A (avec sa base dans la branche principale) sera inaccessible à une demande de tirage pour la branche Feature-B (également basée dans la branche principale).
L'action de cache suit un ordre de recherche spécifique :
Elle cherche d'abord des cache hits dans la même branche que l'exécution du workflow.
Si cela échoue, elle étend la recherche à la branche parente et aux autres branches en amont.
Il est important de noter que l'accès au cache est limité à la branche, s'étendant à tous les workflows et exécutions d'une branche spécifique. De plus, GitHub impose une politique de lecture seule pour les entrées de cache une fois créées, interdisant toute modification.
Implication dans le monde réel : D'une attaque de workflow à faible permission à une attaque de workflow à haute permission
Un scénario CI illustratif démontre comment un attaquant pourrait exploiter le cache poisoning pour élever ses privilèges d'un workflow à faible permission à un workflow à haute permission :
Le workflow Unit-test, responsable de l'exécution des tests unitaires et des outils de couverture de code, est supposé utiliser un outil compromis ou vulnérable. Ce workflow utilise l'action Git action/cache, rendant le cache accessible à tout workflow.
Le workflow Release, chargé de construire et de publier l'artefact de l'application, optimise ses opérations en mettant en cache les dépendances Golang.
Dans ce scénario, le workflow de test unitaire introduit une entrée de cache malveillante en substituant une bibliothèque de journalisation Golang légitime (`go
Last updated
