En juillet 2014, Google a constitué une équipe d'experts en sécurité informatique chargée de trouver des vulnérabilités Zero day non seulement dans les logiciels de Google, mais aussi dans tous les logiciels utilisés par ses utilisateurs. Baptisée Project Zero, l’équipe a alors régulièrement exposé des problèmes de sécurité qu’elle a trouvés. Par exemple, il y a quelques jours, les chercheurs en sécurité ont révélé les détails d'une faille de sécurité activement exploitée du pilote de cryptographie du noyau Windows.Cette fois-ci, Project Zero a publié les détails d'une grave faille de sécurité dans une autre entreprise Microsoft : GitHub. Le bogue concerne les commandes de flux de travail des actions GitHub et est décrit comme étant de haute gravité. Il a été découvert en juillet, mais, conformément à la période de divulgation standard de 90 jours, les détails n’ont été rendus publics que maintenant.
Cette faille est devenue l'une des rares vulnérabilités n'ayant pas été correctement corrigées avant l'expiration du délai standard de 90 jours donné par Google Project Zero. Plus de 95,8 % des failles sont corrigées dans ce délai, selon Google.
Selon Felix Wilhelm, le membre de l’équipe Project Zero qui l’a découverte, la faille affecte la fonctionnalité Actions de GitHub, un outil d'automatisation du travail des développeurs. En effet, les commandes de flux de travail d'Actions sont « vulnérables aux attaques par injection » :
« Actions Github prend en charge une fonctionnalité appelée commandes de workflow en tant que canal de communication entre le runner Action et l'action exécutée. Les commandes de workflow sont implémentées dans runner/src/Runner.Worker/ActionCommandManager.cs et fonctionne en analysant STDOUT de toutes les actions exécutées à la recherche de l'un des deux marqueurs de commande.
« Les commandes V2 doivent commencer au début d'une ligne et ressembler à ceci :
| Code : | Sélectionner tout |
1 2 | ::workflow-command
parameter1={data},parameter2={data}::{command value} |
« Le gros problème de cette fonctionnalité est qu'elle est très vulnérable aux attaques par injection. Comme le processus du runner analyse chaque ligne imprimée vers STDOUT à la recherche de commandes de flux de travail, chaque action GitHub qui contient un contenu non fiable 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 exécuté. J'ai passé un certain temps à regarder les dépôts GitHub populaires et presque tout projet utilisant des actions GitHub un peu complexes est vulnérable à cette classe de bogue ».
Par la suite, il a donné quelques exemples sur la façon dont le bogue pourrait être exploité et a également suggéré une correction :
« Je ne suis vraiment pas sûr de la meilleure façon de résoudre ce problème. Je pense que la manière dont les commandes de workflow sont implémentées est fondamentalement non sécurisée. La dépréciation de la syntaxe de la commande v1 et le renforcement de set-env avec une liste d'autorisation fonctionneraient probablement contre les vecteurs RCE directs.
« Cependant, même la possibilité d'écraser les variables d'environnement "normales" utilisées par les étapes ultérieures est probablement suffisante pour exploiter les actions les plus complexes. Je n'ai pas non plus examiné l'impact sur la sécurité des autres commandes de l'espace de travail.
« Une bonne solution à long terme serait de déplacer les commandes de flux de travail dans un canal non lié (par exemple un nouveau descripteur de fichier) pour éviter d'analyser STDOUT, mais cela brisera beaucoup de code d'action existant (je ne pense pas que cela devrait être résolu en corrigeant simplement les actions vulnérables. Selon le langage de programmation utilisé, il est pratiquement impossible de garantir qu'aucune donnée malveillante ne se retrouvera sur STDOUT). »
En clair, résoudre le problème ne sera pas simple, car il faudrait repenser complètement le fonctionnement de la commande de flux de travail.
La réaction de Microsoft
GitHub a publié un avis le 1er octobre et a déprécié les commandes vulnérables, mais a soutenu que ce que Wilhelm avait trouvé était en fait une « vulnérabilité de sécurité modérée ». GitHub a attribué au bogue l'identifiant CVE-2020-15228 :
« Une vulnérabilité de sécurité modérée a été identifiée dans le programme d'exécution GitHub Actions qui peut permettre l'injection de variable d'environnement et de chemin dans les flux de travail qui consignent des données non approuvées dans STDOUT. Cela peut entraîner l'introduction ou la modification de variables d'environnement sans l'intention de l'auteur du workflow.
« Pour nous permettre de résoudre ce problème et de 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 runners autohébergées, assurez-vous qu'ils sont mis à jour vers la version 2.273.1 ou une version supérieure.
« Les auteurs d'Action qui utilisent la boîte à outils doivent mettre à jour le package @actions/core vers la version 1.2.6 ou une version supérieure pour que les fonctions addPath et exportVariable soient mises à jour.
« Les auteurs d'Action et de flux de travail qui définissent des variables d'environnement via STDOUT doivent mettre à jour toute utilisation des commandes de flux de travail set-env et add-path pour utiliser les nouveaux fichiers d'environnement.
« Si vous avez besoin de consigner des informations non fiables telles que des titres de problèmes, des corps ou des messages de validation dans STDOUT, nous vous recommandons de désactiver le traitement des commandes avant de le faire.
« À titre d'exemple dans bash, vous pouvez faire ce qui suit :
| Code bash : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | jobs:
example-job:
name: example
runs-on: ubuntu-latest
steps:
- name: log untrusted output
run: |
# disable command workflow processing
echo "::stop-commands::`echo -n ${{ github.token }} | sha256sum | head -c 64`"
# log untrusted output
echo "untrusted output"
# enable workflow command processing
echo "::`echo -n ${{ github.token }} | sha256sum | head -c 64`::" |
« Dans JavaScript Action :
| Code JavaScript : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 | import {v4 as uuidv4} from 'uuid' // disable workflow commands const token = uuidv4() console.log(`::stop-commands::${token}`) // log untrusted output console.log("untrusted output") // enable workflow commands console.log(`::${token}::`) |
« Pour les autres langages, vous devez générer un jeton aléatoire approprié qui change à chaque exécution. »
Le même jour, GitHub a publié un avis qui explique aux utilisateurs comment mettre à jour les flux de travail :
Selon Wilhelm, le 12 octobre, Project Zero a contacté GitHub et lui a offert de manière proactive un délai de 14 jours si GitHub voulait plus de temps pour désactiver les commandes vulnérables. Bien entendu l'offre a été acceptée et GitHub espérait désactiver les commandes vulnérables après le 19 octobre. Project Zero a alors fixé la nouvelle date de divulgation au 2 novembre.
Le 28 octobre Project Zero a indiqué à GitHub que le délai expirait la semaine suivante, mais n'a reçu aucune réponse. Étant donné qu'ils n'ont reçu aucune réponse officielle de GitHub, les membres de Project Zero ont décidé de contacter des employés de GitHub. Ces derniers ont expliqué que « la question est considérée comme réglée et que [Project Zero] pouvait rendre le bug public le 2020-11-02 comme prévu », selon les propos de Wilhelm.
Seulement, un jour avant la date limite, GitHub a envoyé sa réponse officielle et a demandé deux jours supplémentaires, le temps d'informer les clients d'un correctif à une date ultérieure. En effet, selon les notes de Wilhelm : « GitHub répond et mentionne qu'ils ne désactiveront pas les commandes vulnérables d'ici le 2020-11-02. Ils demandent un délai supplémentaire de 48 heures, non pas pour résoudre le problème, mais pour informer les clients et fixer une date précise dans le futur ». Néanmoins, selon les politiques de divulgation de Google, la période de divulgation d'un bogue ne peut s'étendre au-delà de 104 jours (notamment 90 jours de base et 14 jours de grâce). Aussi, Project Zero a procédé à la divulgation le 2 novembre 2020.
Sources : Google Project Zero, GitHub (1, 2)
Et vous ?
Que pensez-vous de la politique de divulgation de Google Project Zero (90 jours de base et 14 jours de grâce) ? Utilisez-vous cet outil sur GitHub ? Si oui, allez-vous procéder à une mise à jour ? 
