- Sur GitHub, il est possible d’accéder aux données de forks supprimés, de dépôts supprimés, et même de dépôts privés
- GitHub est au courant de ce comportement et il s’agit d’un fonctionnement volontaire
- Comme cela constitue un énorme vecteur d’attaque pour toute organisation utilisant GitHub, un nouveau terme est proposé : « référence d’objet inter-fork croisée (CFOR) »
- Une vulnérabilité CFOR se produit lorsqu’un fork d’un dépôt peut accéder à des données sensibles d’un autre fork, y compris des données issues de forks privés ou supprimés
Accéder aux données d’un fork supprimé
- Si l’on considère un workflow courant sur GitHub, on peut forker un dépôt public, valider du code dans ce fork, puis supprimer le fork
- Le code validé dans le fork reste accessible, et le restera indéfiniment
- On pourrait penser qu’il est protégé tant qu’il faut connaître le hash du commit, mais ce hash peut être découvert
- Retrouver des données dans un fork supprimé se produit assez fréquemment
Accéder aux données d’un dépôt supprimé
- Si l’on prend le scénario où un dépôt public existe sur GitHub, qu’un utilisateur le fork, y valide des données après le fork, puis supprime entièrement le dépôt,
- le code validé après le fork reste toujours accessible
- GitHub stocke les dépôts et leurs forks dans un réseau de dépôts, le dépôt « upstream » d’origine jouant le rôle de nœud racine
- Si le dépôt public « upstream » forké est « supprimé », GitHub réattribue le rôle de nœud racine à l’un des forks en aval
- Cependant, tous les commits du dépôt « upstream » continuent d’exister et restent accessibles via n’importe lequel des forks
Accéder aux données d’un dépôt privé
- Si l’on considère un workflow courant d’open source d’un nouvel outil sur GitHub,
- il peut arriver qu’on crée un dépôt privé destiné à devenir public, qu’on en crée une version interne privée (via un fork), qu’on y valide du code supplémentaire pour des fonctionnalités qui ne seront pas publiées, puis qu’on rende le dépôt « upstream » public tout en gardant le fork privé
- Les fonctionnalités privées et le code associé (à l’étape 2), s’ils sont visibles publiquement ou non, sont accessibles depuis le dépôt public
- Tout ce qui est validé dans le fork privé après la publication du dépôt « upstream » n’est pas visible
Comment accéder concrètement aux données ?
- En accédant directement aux commits
- Dans le réseau de dépôts de GitHub, les opérations destructrices (comme les trois scénarios mentionnés ci-dessus) suppriment les références aux données de commit dans l’interface standard de GitHub et dans les opérations git habituelles
- Cependant, ces données existent toujours et restent accessibles si l’on connaît le hash du commit
- Un hash de commit est une valeur SHA-1, et si un utilisateur connaît le hash SHA-1 du commit précis qu’il veut consulter, il peut accéder directement à ce commit via l’endpoint https://github.com/<user/org>/…;
- Les hashes de commit peuvent être bruteforcés via l’interface de GitHub
- Il est également possible d’interroger les hashes de commit via l’endpoint public events API de GitHub
La politique de GitHub
- Ces résultats ont récemment été soumis via le programme VDP de GitHub, et GitHub a clairement indiqué que les dépôts sont conçus pour fonctionner ainsi
- Après examen de la documentation, il apparaît que GitHub documente clairement ce à quoi les utilisateurs doivent s’attendre dans les cas décrits ci-dessus
Impact
- Tant qu’il existe au moins un fork, tous les commits de ce réseau de dépôts (qu’ils proviennent du dépôt « upstream » ou d’un fork « downstream ») existeront pour toujours
- L’architecture des dépôts de GitHub nécessite ce défaut de conception, et la majorité des utilisateurs de GitHub ne comprennent pas réellement comment fonctionne le réseau de dépôts, ce qui les rend moins en sécurité
- À mesure que le secret scanning évolue et devient capable de scanner tous les commits d’un réseau de dépôts, il deviendra possible d’être alerté sur des secrets qui ne sont pas les siens
- Ces trois scénarios sont choquants, mais ne couvrent pas toutes les façons dont GitHub peut conserver des données supprimées dans un dépôt
L’avis de GN⁺
- Cet article soulève un problème de sécurité important pour les organisations qui utilisent GitHub. Le fait que les données de dépôts supprimés ou rendus privés restent accessibles est choquant. Cela semble être un défaut de conception fondamental lié à l’architecture du réseau de dépôts de GitHub
- Les développeurs doivent être conscients de ce problème et faire preuve de prudence lorsqu’ils valident des données sensibles ou des secrets sur GitHub. Une fois poussés vers un dépôt public, ils peuvent rester accessibles indéfiniment. En cas de fuite de secrets importants, seule une rotation des clés permet d’y remédier complètement
- GitHub rend ce problème public de manière transparente et le documente, mais la majorité des utilisateurs ne comprendront probablement pas complètement le fonctionnement du réseau de dépôts. GitHub devrait faire davantage d’efforts pour sensibiliser et former ses utilisateurs à ce sujet
- Des problèmes similaires peuvent exister dans d’autres systèmes de gestion de versions. Les développeurs et les organisations doivent bien comprendre l’architecture et les limites des outils qu’ils utilisent lorsqu’ils gèrent des données sensibles
- Pour éviter les fuites de données sensibles, il faut mettre en place des mesures de sécurité à plusieurs niveaux, comme des contrôles d’accès stricts, l’application du principe du moindre privilège, un secret scanning régulier et une surveillance continue. Plus que tout, un niveau élevé de sensibilisation à la sécurité chez les développeurs est essentiel
1 commentaires
Avis Hacker News