IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Mars 2013
    Messages
    8 454
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : Mars 2013
    Messages : 8 454
    Points : 197 762
    Points
    197 762
    Par défaut Google dévoile une faille de sécurité « grave » concernant la plateforme GitHub de Microsoft
    Le Project Zero de Google dévoile une faille de sécurité « grave » concernant la plateforme GitHub de Microsoft,
    aucun correctif n'est disponible pour le moment et les utilisateurs sont invités à faire des mises à jour

    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 - Visualiser dans une fenêtre à part
    1
    2
    ::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 ».

    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.

    Nom : github.png
Affichages : 63564
Taille : 64,6 Ko

    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 - Visualiser dans une fenêtre à part
    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 - Visualiser dans une fenêtre à part
    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 :

    Nom : instructions.png
Affichages : 5774
Taille : 28,0 Ko

    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 ?
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre extrêmement actif
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Octobre 2017
    Messages
    1 786
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Octobre 2017
    Messages : 1 786
    Points : 5 742
    Points
    5 742
    Par défaut
    Google dévoile une faille de sécurité « grave » concernant la plateforme GitHub de Microsoft
    Reste juste à savoir combien de temps va devoir attendre la communauté avant que Microsoft dévoile une faille de sécurité grave chez Google

  3. #3
    Membre du Club
    Homme Profil pro
    Développeur Web
    Inscrit en
    Octobre 2020
    Messages
    36
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Octobre 2020
    Messages : 36
    Points : 67
    Points
    67
    Par défaut
    Incroyable cette histoire. Merci pour cette news détaillée en tout cas.

    Développeur freelance à Toulouse - site en construction

Discussions similaires

  1. Réponses: 1
    Dernier message: 10/02/2020, 11h59
  2. Réponses: 0
    Dernier message: 19/02/2018, 18h03
  3. Réponses: 9
    Dernier message: 19/08/2016, 21h43
  4. Microsoft dévoile une faille de sécurité dans Internet Explorer
    Par Stéphane le calme dans le forum Sécurité
    Réponses: 13
    Dernier message: 06/05/2014, 17h27

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo