Le Fork s'éveille : Pourquoi les réseaux invisibles de GitHub compromettent la sécurité des packages

Cher GitHub,

Voici le problème : il existe un problème de sécurité qui est un secret de polichinelle depuis un certain temps déjà. Les gens en parlent dans les outils de suivi des problèmes. Il est mentionné dans les divulgations de sécurité. Il fait l'objet de discussions dans les fils Slack qui se terminent inévitablement par «... mais il faudrait que GitHub expose réellement ces données ». 

Je porte cela à votre attention parce que je suis fatigué de voir cette conversation se terminer toujours de la même manière. La communauté de la sécurité demande simplement à avoir accès aux données dont vous disposez déjà. Sans cela, nous sommes bloqués. Les registres de paquets ne peuvent pas avertir les utilisateurs. Les outils de sécurité ne peuvent pas signaler les références suspectes. Les attaquants, quant à eux, comprennent parfaitement ce point faible. Ils l'exploitent déjà, tout comme Shai Hulud l'a fait.

Les fêtes approchent. Et j'aime à penser que j'ai été plutôt sage cette année. Mon seul souhait est que vous nous donniez les outils nécessaires pour mieux protéger l'écosystème. J'espère que ce n'est pas trop demander !

Quel est le problème ?

Les gestionnaires de paquets tels que votre propre npm, ainsi que des tiers tels que Bun et PyPI, permettent aux développeurs d'installer un référentiel GitHub directement en tant que dépendance. Vos propres actions GitHub s'appuient sur cette même primitive.

npm install github:trusted-org/trusted-package#commit-sha

bun install github:trusted-org/trusted-package#commit-sha‍

pip install git+https://github.com/trusted-org/trusted-package#commit

- utilise : trusted-org/trusted-package@commit-sha

La plupart des gens regarderaient cela et se demanderaient : «Où est le problème de sécurité ? Je spécifie littéralement le référentiel exact. »

Oui. J'ai pensé la même chose.

Mais voici ce qui se passe : si ce SHA de validation existe dans une fourche du dépôt, vous allez extraire le code de la fourche. Pas du dépôt dans votre URL. De la fourche. Mais qu'est-ce que c'est que ça ?

Réfléchissez-y un instant. Je vous attends... L'URL indique organisation-de-confiance/paquet-de-confianceMais si un pirate informatique a copié ce dépôt, ajouté un commit malveillant et vous a amené à référencer le SHA de ce commit, vous venez d'installer son code. Pas le code que vous pensiez. Pas le dépôt que vous avez spécifié. Le sien.

Pourquoi cela se produit-il ?

Cela est dû au «réseau Fork » de GitHub.

Il y a fort à parier que vous n'en avez jamais entendu parler. Voici comment cela fonctionne : lorsque vous créez une fourche d'un dépôt, vous n'obtenez pas une copie totalement indépendante. Votre fourche rejoint un réseau, partageant le magasin d'objets git sous-jacent avec l'original et toutes les autres fourches. C'est ainsi que GitHub gère l'évolutivité. Ils ne stockent pas un million de copies des mêmes commits. C'est logique.

C'est aussi pourquoi cette attaque fonctionne.

Les commandes ci-dessus aboutissent finalement à la page «Télécharger une archive du référentiel (tar)« endpoint ». Les documents indiquent ceci à propos du propriétaire paramètre :

Il n'y a aucune garantie que le code appartienne directement au référentiel, ni d'avertissement indiquant qu'il pourrait provenir d'une fourche. Honnêtement ? Compte tenu de l'architecture, ce comportement est logique. Le commit existe dans le graphe partagé. GitHub le sert. Il n'y a rien de mal à cela.

Quoi ? est Le problème est que cela crée une ambiguïté que personne d'autre ne peut percevoir. Vous demandez organisation de confianceVous obtenez le code de l'attaquant. GitHub a répondu à votre demande. Mais vous n'avez pas obtenu ce que vous pensiez demander. Et aucun outil en dehors de GitHub ne peut faire la différence.

L'asymétrie 

Écoutez, nous avons vraiment apprécié que vous ajoutiez cette bannière d'avertissement sur GitHub.com. Voir un avertissement pour des commits comme ceux-ci ? C'est utile. Cela montre que vous savez que c'est un problème qui mérite d'être signalé.

Mais voici le problème : les gestionnaires de paquets ne consultent pas votre site web. Ils appellent votre API. Et l'API ne leur donne aucune indication qu'il se passe quelque chose d'inhabituel. Aucun indicateur, aucune métadonnée, rien de documenté. Npm ne peut donc pas avertir les utilisateurs. PyPI ne peut pas avertir les utilisateurs. Bun ne peut pas avertir les utilisateurs. L'information existe. Vous la mettez déjà en avant sur l'interface utilisateur. Mais l'écosystème ne peut pas y accéder.

Pourquoi pas ?

Il est temps d'être strict

Vous vous souvenez de ce point de terminaison «Télécharger une archive de référentiel (tar) » dont nous avons parlé ? À l'heure actuelle, c'est le maillon faible. Mais c'est aussi l'endroit évident où corriger cela.

Voici une idée : ajoutez un strict paramètre. Lorsqu'il est défini, la requête échoue si la validation n'existe que dans une fourche, et non dans le référentiel spécifié. Les gestionnaires de paquets optent pour cette option, tous les autres conservent le comportement actuel, rien ne change.

Vous effectuez déjà cette vérification sur l'interface utilisateur pour cette bannière d'avertissement. Il suffit de donner à l'API la même capacité. Bien sûr, l'idéal serait que vous puissiez exposer davantage d'informations sur le réseau fork dans votre API en général, mais cela résout au moins le problème le plus flagrant.

Joyeuses fêtes !

Je n'écris pas ceci pour me plaindre. J'écris parce que nous sommes tous d'accord pour vouloir un écosystème sûr et fiable. Vous avez déjà reconnu le problème en affichant l'avertissement sur GitHub.com. Il serait désormais très utile de diffuser ce même signal via l'API afin que l'écosystème puisse agir en conséquence.

Une petite amélioration de votre part permettrait une amélioration significative de l'ensemble de l'écosystème. N'est-ce pas là le meilleur type d'amélioration ? 

Et comme c'est la période des fêtes, je voudrais partager quelque chose que j'ai entendu en coulisses. Au cours des dernières semaines, j'ai discuté avec certains des acteurs les plus importants de l'écosystème, et il y a une inquiétude silencieuse et partagée que quelque chose puisse mal tourner alors que tout le monde essaie de prendre des congés pour passer du temps avec ses proches. Bien sûr, régler ce problème ne supprimera pas ce risque, mais cette inquiétude est réelle et largement partagée.

Joyeuses fêtes, GitHub. Nous vous souhaitons une fin d'année sereine.

‍