Des chercheurs de Truffle Security ont récemment mis en lumière, ou plutôt redécouvert, que les données provenant de dépôts GitHub supprimés (qu’ils soient publics ou privés) ainsi que celles des copies supprimées (forks) de ces dépôts ne sont pas nécessairement effacées.
Joe Leon, un chercheur en sécurité de l’entreprise, a déclaré dans un avis publié mercredi que l’accès aux données de dépôts supprimés – comme les clés API – constitue un risque pour la sécurité. Il a proposé un nouveau terme pour décrire cette vulnérabilité présumée : Référence d’Objet de Fork Croisé (ROFC).
« Une vulnérabilité ROFC se produit lorsqu’un fork d’un dépôt peut accéder à des données sensibles d’un autre fork (y compris celles de forks privés et supprimés) », a expliqué Leon.
Par exemple, l’entreprise a démontré comment il est possible de forker un dépôt, d’y ajouter des données, de supprimer le fork, puis d’accéder aux données de commit censées être supprimées via le dépôt d’origine.
Les chercheurs ont également créé un dépôt, l’ont forké, et ont montré comment des données non synchronisées avec le fork restent accessibles à travers celui-ci même après la suppression du dépôt d’origine. Vous pouvez visionner cette démonstration ci-dessous.
Vidéo YouTube
Selon Leon, ce scénario a été mis en lumière la semaine dernière lors de la soumission d’un rapport de vulnérabilité critique à une grande entreprise technologique, impliquant une clé privée pour un compte GitHub d’employé ayant un accès étendu à l’organisation. Cette clé avait été publiquement engagée dans un dépôt GitHub. En prenant conscience de l’erreur, l’entreprise a supprimé le dépôt, pensant que cela résoudrait le problème de fuite.
« Ils ont immédiatement supprimé le dépôt, mais comme il avait été forké, j’ai pu accéder au commit contenant les données sensibles via un fork, même si ce fork n’avait jamais été synchronisé avec le dépôt d’origine », a expliqué Leon.
Leon a ajouté qu’après avoir examiné trois dépôts publics largement forkés d’importantes entreprises d’IA, les chercheurs de Truffle Security ont trouvé 40 clés API valides provenant de forks supprimés.
Les forks en question
Il est clair que cela pose un problème. Cependant, ce n’est pas un problème que GitHub considère comme une vulnérabilité légitime. En fait, le géant de l’hébergement de code, propriété de Microsoft, le considère comme une fonctionnalité, et non comme un bug.
Lorsqu’il a été informé de la situation par le biais de son Programme de Divulgation de Vulnérabilités, GitHub a répondu : « C’est une décision de conception intentionnelle et cela fonctionne comme prévu, comme indiqué dans notre [documentation]. »
C’est une décision de conception intentionnelle et cela fonctionne comme prévu
Cela, manifestement, est connu depuis des années. Une personne prétend avoir informé GitHub de cette vulnérabilité en 2018 et avoir reçu une réponse similaire.
Dans une interview téléphonique avec The Register, Dylan Ayrey, co-fondateur et PDG de Truffle Security, a expliqué que le problème réside dans ce qu’on appelle un commit suspendu.
« Un commit suspendu est un élément fondamental de Git », a expliqué Ayrey. « Ce n’est pas un élément spécifique à GitHub. Ainsi, un commit suspendu peut exister sur n’importe quelle plateforme Git – Bitbucket, GitLab, GitHub, etc. Un commit suspendu se trouve dans un dépôt de code donné, où vous avez un arbre représentant l’historique de ce projet, donc toutes les anciennes versions du code qui sont liées entre elles. »
Un commit Git capture un instantané de l’état d’un dépôt à un moment donné, y compris les modifications apportées au code et aux données. Chaque commit est identifié de manière unique par un hachage cryptographique. Bien que la suppression d’une branche, par exemple, retire la référence à une chaîne de commits particulière, les commits eux-mêmes ne sont pas supprimés de la base de données d’objets du dépôt.
« Ces commits suspendus sont comme une partie fondamentale documentée de Git lui-même », a déclaré Ayrey, qui a expliqué que la manière dont les plateformes Git gèrent les commits suspendus est une décision de plateforme plutôt qu’une spécification de Git.
Bitbucket, GitLab et GitHub, a déclaré Ayrey, conservent ces commits même lorsque la connexion à l’arbre de code est rompue. Si vous avez l’identifiant pour y accéder directement, vous pouvez toujours télécharger les données associées.
- Oups. Apple s’est appuyé sur un code défectueux tout en critiquant la technologie publicitaire Topics de Google Chrome
- Les mois et jours avant et après le vendredi fatal de CrowdStrike
- Kaspersky affirme que l’oncle Sam a snobé une proposition d’ouverture de son code à un examen tiers
- Oubliez la sécurité – le reCAPTCHA v2 de Google exploite les utilisateurs à des fins de profit
Ayrey a déclaré que cela est largement connu. Mais il existe un problème connexe concernant les forks – dépôts copiés – qui est plus spécifique à GitHub. Les forks, a-t-il expliqué, ne font pas partie de la spécification Git, donc chaque plateforme a sa propre mise en œuvre.
Ayrey a précisé que pour GitHub, les commits suspendus peuvent être téléchargés via un fork si vous avez le hachage identifiant, ou une partie de celui-ci.
« Si vous avez l’identifiant, vous pouvez les télécharger depuis le dépôt où ils ont été initialement poussés », a-t-il expliqué. « Il s’avère que vous pouvez également les télécharger à travers n’importe quel fork de ce dépôt. Et cela fonctionne dans les deux sens. Ainsi, depuis le parent, vous pouvez télécharger ce commit suspendu depuis le fork et depuis le fork, vous pouvez télécharger ce commit suspendu depuis le parent. »
« Ce que nous avons découvert, c’est que même si vous supprimez le parent, et que le commit a été poussé vers le parent, ce commit suspendu non seulement continue d’exister, mais vous pouvez le télécharger à travers l’enfant même s’il a été poussé vers le parent, qu’il n’a jamais été tiré dans l’enfant, et que le parent a été supprimé, vous pouvez maintenant accéder à ce commit suspendu. »
Ce commit suspendu non seulement continue d’exister, vous pouvez le télécharger à travers l’enfant même s’il a été poussé vers le parent
De plus, Ayrey a expliqué qu’il n’est même pas nécessaire d’avoir le hachage identifiant complet pour accéder au commit. « Si vous connaissez les quatre premiers caractères de l’identifiant, GitHub complétera presque automatiquement le reste de l’identifiant pour vous », a-t-il déclaré, notant qu’avec seulement soixante-cinq mille combinaisons possibles pour ces caractères, c’est un nombre suffisamment petit pour tester toutes les possibilités.
Interrogé sur les risques que cela présente, Ayrey a mentionné qu’il existe un archive des événements GitHub qui enregistre toutes les actions publiques sur la plateforme. Et il a ajouté que tout comme l’archive de tweets de la Sunlight Foundation pourrait être utilisée pour rechercher des déclarations publiques sur les réseaux sociaux, l’archive des événements de GitHub peut être utilisée pour des enquêtes judiciaires sur les activités des entreprises technologiques.
« Si [les entreprises technologiques] suppriment du code, si elles font tout leur possible pour supprimer quelque chose, cela ne signifie pas toujours quelque chose », a-t-il expliqué. « Mais souvent, cela signifie quelque chose. Cela pourrait signifier qu’une clé ou un mot de passe a été exposé. Cela pourrait signifier qu’elles ont accidentellement poussé un ensemble de données d’apprentissage automatique. Nous avons déjà vu cela. Ou cela pourrait signifier – et c’est rare – qu’un attaquant a réellement introduit une porte dérobée dans leur projet et qu’elles étaient un peu embarrassées à ce sujet… donc elles ont simplement supprimé la porte dérobée. »
Interrogé sur la manière dont GitHub devrait réagir, Ayrey a réfléchi : « Si une plateforme crée une vulnérabilité, la documente et explique que c’est quelque chose dont vous devez être conscient, est-ce que cela en fait moins une vulnérabilité ? »
« Ce que je recommanderais probablement, si je travaillais là-bas, c’est que ce pool de forks ne soit pas partagé entre les forks, que les commits que vous poussez vers un fork ne puissent pas être téléchargés à travers un autre fork. L’autre chose que je recommanderais probablement serait de créer une nouvelle fonctionnalité permettant de supprimer définitivement les commits et non simplement de les laisser suspendus. »
Truffle Security soutient que GitHub devrait reconsidérer sa position, car l’utilisateur moyen s’attend à ce qu’il y ait une distinction entre les dépôts publics et privés en termes de sécurité des données, ce qui n’est pas toujours vrai. Il y a également l’attente que l’acte de suppression devrait éliminer les données de commit, ce qui, encore une fois, a été prouvé ne pas toujours être le cas.
Un porte-parole de GitHub a déclaré à The Register : « GitHub s’engage à enquêter sur les problèmes de sécurité signalés. Nous sommes conscients de ce rapport et avons validé qu’il s’agit d’un comportement attendu et documenté inhérent à la manière dont fonctionnent les réseaux de forks. Vous pouvez en savoir plus sur la manière dont la suppression ou le changement de visibilité affecte les forks de dépôts dans notre documentation. »
