Elle a été découverte le 21 juillet, ouvrant une fenêtre de 90 jours après avertissement de GitHub. Ce dernier a demandé une extension de 14 jours, portant la limite au 2 novembre. La faille étant toujours présente, Google en publie donc les détails.
Elle réside dans la manière dont le service gère les commandes de flux de travail. Selon l’équipe du Project Zero, le fonctionnement de ces commandes est « fondamentalement dangereux ». Ce qui explique sans doute pourquoi la brèche n’est pas colmatée.
Ces commandes agissent comme un canal de communication entre les actions à exécuter et l’Action Runner. Puisque ce dernier analyse (parse) chaque ligne présente dans STDOUT, toute action comportant du contenu non fiable est vulnérable. En clair, le canal est sensible aux attaques par injection.
Le fait est que Google ignore comment GitHub peut se dépêtrer de cette situation, car il faudrait revoir intégralement le fonctionnement des commandes, ce qui casserait immanquablement la compatibilité avec le code en ayant besoin.
Le 1er octobre, GitHub a fait parvenir un message aux développeurs, pour les avertir que les commandes vulnérables allaient être dépréciées et qu’il fallait mettre à jour les flux de travail. L’éditeur y évoquait une vulnérabilité de dangerosité « modérée ». On attend toujours une date fixe, ce d’autant plus que les détails de la faille sont maintenant publics.
Commentaires (11)
#1
La plus grosse faille de Github se nomme Microsoft.
#2
Si tu veux être crédible, met un “$” à la place du “s” dans microsoft,
#2.1
non
#3
On en est encore là en 2020… Les idées reçues sont tenaces…
#4
Des arguments à cette affirmation ?
#5
Oui, le
^^
#6
Microsoft justement a apporté la connexion u2f a GitHub et personnellement j’ai grandement hate qu’il apporte leur connexion paswordless (via le compte Microsoft ?), car Google lui par contre a un retard considérable et visiblement tape dans Microsoft (deux fois en peu de temps) pour essayé de les faire passé pour non fiable (j’imagine que le nouvelle edge marche sur leur plat de bande).
C’est un arguments ca ? ou juste une pensée libriste sans aucun réel raisonnements derrière ?
on est pas trolldi pourtant :/
#7
C’est quand même une faille un peu à part, dans le sens où un utilisateur lambda ne sera pas affecté, déjà parce qu’il n’ira pas à l’endroit précis où la faille existe, ensuite parce que son navigateur est à jour, et enfin on parle d’un environnement relativement maîtrisé (c’est le dev et contributeurs qui vont éventuellement être concernés par le contenu incriminé, Lesdits runners, en général, on ne regarde que leur résultat dans un overlay, on ne regarde et donc ne parse pas les traces).
Rien à voir avec une faille qui pourrait donner le contrôle du repository ou de la machine à un attaquant, par exemple. Bref, du bruit pour pas grand chose, et Google qui en fait un peu trop.
C’est plutôt Chrome qui était à blâmer, sauf qu’il a été patché… :-)
#7.1
Je n’ai pas regardé les détails de cette faille, mais je sais que les devs ont souvent tendance à négliger les vulnérabilités dans les process de build (ça tourne pas en prod donc c’est pas grave). Je ne sais pas si c’est un risque ici, mais les injections de code malicieux via des vulnérabilités dans le build, ça s’est déjà vu (et à la fin ça impacte quand même la prod).
#8
Après lecture du rapport, je n’en serais pas si sûr. Il dit, si j’ai bien compris, qu’il peut récupérer (sous certaines conditions) les variables d’environnement du build (“dumps the process environment”). Et que contiennent parfois ces variables ? Des tokens d’accès pourquoi pas?, ( Par exemple à des registry type docker)
#9
Accessoirement Github a déjà mis en place une solution de contournement, à base d’un fichier dans lequel sont placées les variables d’environnement, en lieu et place de STDOUT. Le problème réside principalement dans des Github Actions existantes qui seraient utilisées sans en avoir lu le code.