Une faille de sécurité grave sur la plate-forme GitHub dévoilée par les chercheurs de Google

Depuis 2014, le géant américain du numérique Google, dispose de sa propre équipe spécialisée en sécurité informatique.

Leur spécialité se situe au niveau de la recherche de vulnérabilité de type 0 Day. Mais leur rôle de ne se limite pas tout simplement à analyser les logiciels et programmes informatiques de Google, ils emploient souvent son talent à l’analyse d’autres programmes fournis pas d’autres éditeurs. L’équipe à chaque fois découvert des vulnérabilités assez graves qu’elle a par la suite publié dans le but de permettre aux éditeurs de la combler. L’équipe a été baptisée le Project de Zero.

Cet article va aussi vous intéresser : GitHub ouvre sa plateforme de cybersécurité

Récemment, le Project Zero de Google a fait parler de lui. Les chercheurs de géant américain ont découvert et exposé des problèmes de cybersécurité affilié à une plate-forme célèbre. Il s’agit d’une vulnérabilité touchant un pilote de cryptographie du noyau de Windows, Le système d’exploitation de Microsoft un autre géant américain. Par la suite, c’est une autre faille de sécurité affectant une plate-forme une autre plateforme de Microsoft encore, connu GitHub. La vulnérabilité touche la commande de flux de travail des actions réalisées sur la plate-forme. Les chercheurs la décrivent comme étant assez grave. La découverte a été faite depuis le mois de juillet mais conformément aux règles selon laquelle il faudra attendre 90 jours avant de publier une vulnérabilité, les détails ont tardé avant de paraître au grand jour. Malheureusement, la faille de sécurité n’a pas été correctement corrigée avant l’expiration de ce délai donner à l’équipe de recherche de Google. Cependant 95,8 % des vulnérabilités ont été résolu selon les chercheurs du Project Zero.

La vulnérabilité est expliquée par l’un des membres de l’équipe de recherche de Google. Félix Wilhelm. Selon ce dernier la faille de sécurité touche essentiellement la fonctionnalité d’action de GitHub. Une fonctionnalité utilisée par beaucoup de développeur comme outils d’automatisation. Il signifie que ces commandes sont généralement « vulnérables aux attaques par injection ». Il ajoutera à part la suite : 

« 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

::workflow-command

parameter1={data},parameter2={data}::{command value}

Les commandes V1 peuvent également commencer au milieu d’une ligne et avoir la syntaxe suivante : ##[command parameter1=data;]command-value. La version actuelle du runner Action GitHub prend en charge un petit nombre de commandes différentes, mais la plus intéressante du point de vue de la sécurité est set-env. Comme son nom le suggère, set-env peut être utilisé pour définir des variables d’environnement arbitraires dans le cadre d’une étape de workflow. Un exemple simple (dans la syntaxe V1) serait ##[set-env name=VERSION;]alpha qui place VERSION=alpha dans l’environnement de toutes les étapes suivantes d’un flux de travail.

« 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 ».

Après ces explications, le spécialiste de Google a fait certaines démonstrations pour montrer de quelle manière l’on peut exploiter la faille de sécurité tout en suggérant une manière de la corriger.

« 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). » démontre Félix Wilhelm.

Par conséquent, il faudrait être sûr que résoudre ce problème de sera pas une mince affaire. Il faudrait totalement revoir l’ensemble de la commande gérant le plein de travail.

De son côté les responsables de la plate-forme, ont publié le 1er octobre dernier, un avis et une dépréciation des commandes vénérables. Ils reconnaissent que la vulnérabilité est bel et bien réelle mais qu’elle est tout simplement modérée. Elle fut alors baptisée : CVE-2020-15228.

Accédez maintenant à un nombre illimité de mot de passe :