Project Zero a publié les détails d'une grave faille de sécurité sur GitHub et ils rapportent que l'erreur affecte les commandes de workflow d'action de GitHub et est décrit comme une gravité élevée. (Ce bogue a été découvert en juillet, mais sur la base de la période de divulgation standard de 90 jours, les détails n'ont été publiés que maintenant.)
Cette faille est devenue l'une des rares vulnérabilités qui n'a pas été corrigée correctement avant l'expiration du délai standard de 90 jours accordé par Google Project Zero.
D'après Felix Wilhelm (qui l'a découvert), membre de l'équipe Project Zero, la faille affecte la fonction actions de GitHub, un outil pour automatiser le travail des développeurs. En effet, les commandes de workflow Actions sont «vulnérables aux attaques par injection»:
«Actions Github prend en charge une fonctionnalité appelée commandes de workflow comme canal de communication entre le courtier d'action et l'action exécutée. Les commandes de flux de travail sont implémentées dans / src / Runner.Worker / ActionCommandManager.cs et fonctionnent en analysant STDOUT de toutes les actions effectuées en recherchant l'un des deux marqueurs de commande.
Mentionnez que le gros problème de cette fonctionnalité est qu'elle est très vulnérable aux attaques par injection. Étant donné que le processus d'exécution analyse chaque ligne imprimée dans STDOUT pour les commandes de flux de travail, chaque action GitHub qui contient du contenu non approuvé dans le cadre de son exécution est vulnérable.
Dans la plupart des cas, la possibilité de définir des variables d'environnement arbitraires entraîne l'exécution de code à distance dès qu'un autre flux de travail est en cours d'exécution. J'ai passé du temps à regarder les référentiels GitHub populaires et presque tous les projets utilisant des actions GitHub légèrement complexes sont vulnérables à ce type de bogue.
Par la suite, a donné quelques exemples de la manière dont le bogue pourrait être exploité et a également suggéré une solution:
«Je ne sais vraiment pas quelle est la meilleure façon de résoudre ce problème. Je pense que la façon dont les commandes de flux de travail sont implémentées est fondamentalement non sécurisée. La dépréciation de la syntaxe de la commande v1 et le renforcement deet-env avec une liste d'autorisation fonctionneraient probablement contre les vecteurs RCE directs.
«Cependant, même la possibilité de remplacer les variables d'environnement« normales »utilisées dans les étapes ultérieures est probablement suffisante pour exploiter les actions les plus complexes. Je n'ai pas non plus analysé l'impact sur la sécurité des autres contrôles dans l'espace de travail.
Par ailleurs, mentionnez qu'une bonne solution à long terme Ce serait de déplacer les commandes de flux de travail vers un canal séparé (par exemple, un nouveau descripteur de fichier) pour éviter l'analyse par STDOUT, mais cela brisera beaucoup de code d'action existant.
Quant à GitHub, ses développeurs ont publié un avis le 1er octobre et ont désapprouvé les commandes vulnérables, mais ont fait valoir que ce que Wilhelm avait trouvé était en fait une «vulnérabilité de sécurité modérée». GitHub a attribué l'identifiant de bogue CVE-2020-15228:
«Une vulnérabilité de sécurité modérée a été identifiée dans le runtime Actions GitHub qui peut permettre l'injection de chemins et de variables d'environnement dans les workflows qui consignent des données non approuvées dans STDOUT. Cela peut conduire à l'introduction ou à la modification de variables d'environnement sans l'intention de l'auteur du workflow.
«Pour nous aider à résoudre ce problème et vous permettre de définir dynamiquement des variables d'environnement, nous avons introduit un nouvel ensemble de fichiers pour gérer les mises à jour d'environnement et de chemin dans les flux de travail.
«Si vous utilisez des courtiers auto-hébergés, assurez-vous qu'ils sont mis à jour vers la version 2.273.1 ou supérieure.
Selon Wilhelm, le 12 octobre, Project Zero a contacté GitHub et leur a proposé de manière proactive une fenêtre de 14 jours si GitHub voulait plus de temps pour désactiver les commandes vulnérables. Bien sûr, l'offre a été acceptée et GitHub espérait désactiver les commandes vulnérables après le 19 octobre. Project Zero a ensuite fixé la nouvelle date de divulgation pour le 2 novembre.
source: https://bugs.chromium.org