Il a été récemment annoncé qu'une vulnérabilité critique avait été identifiée dans le dépôt de paquets RubyGems.org (la vulnérabilité est déjà répertoriée sous la référence CVE-2022-29176), qui permet , sans autorisation appropriée, le remplacement des paquets d'autres personnes dans le dépôt en initiant le retrait (yank) d'un paquet légitime et en téléchargeant à sa place un autre fichier portant le même nom et le même numéro de version.
Il est mentionné que la vulnérabilité est due à un bug dans le gestionnaire d'actions « yank » , qui traite la partie du nom après le tiret comme le nom de la plateforme, ce qui permet de déclencher la suppression des packages externes qui correspondent dans la partie du nom jusqu'au caractère tiret.
En particulier, dans le code du gestionnaire d'opération « yank », l'appel « find_by!(full_name: "#{rubygem.name}-#{slug}") » a été utilisé pour rechercher des paquets, tandis que le paramètre « slug » a été transmis au propriétaire du paquet pour déterminer la version à supprimer.
Le propriétaire du package "rails-html" aurait pu spécifier "sanitizer-1.2.3" au lieu de la version "1.2.3", ce qui entraînerait l'application de l'opération au "rails-html-sanitizer-1.2.3" paquet ″ de quelqu'un d'autre. »
Un avis de sécurité pour Rubygems.org a été publié hier.
L'avis concernait un bogue qui permettait à un utilisateur malveillant d'exploiter certaines gemmes et de télécharger différents fichiers avec le même nom, le même numéro de version et une plate-forme différente.
Examinons de plus près ce qui n'a pas fonctionné lors du processus d'extraction. Comme prétexte, imaginons un scénario où nous créons une gemme appelée "rails-html" avec l'intention d'obtenir un accès non autorisé à la gemme "rails-html-sanitizer" largement utilisée.
Il est indiqué que trois conditions doivent être remplies pour exploiter avec succès cette vulnérabilité :
- L'attaque ne peut être effectuée que sur les paquets dont le nom contient un trait d'union.
- Un attaquant devrait pouvoir placer un pack de gemmes avec une partie du nom jusqu'au trait d'union. Par exemple, si l'attaque est contre le package "rails-html-sanitizer", l'attaquant doit mettre son propre package "rails-html" dans le référentiel.
- Le package attaqué doit avoir été créé dans les 30 derniers jours ou non mis à jour depuis 100 jours.
Le problème a été identifié par un chercheur en sécurité dans le cadre du programme de primes de HackerOne visant à détecter les failles de sécurité dans les projets open source connus.
Le problème a été corrigé sur RubyGems.org le 5 mai et, selon les développeurs, aucune trace d'exploitation de la vulnérabilité n'a été détectée dans les journaux au cours des 18 derniers mois. Toutefois, seul un audit superficiel a été réalisé jusqu'à présent, et un audit plus approfondi est prévu.
À l'heure actuelle, nous pensons que cette vulnérabilité n'a pas été exploitée.
RubyGems.org envoie un e-mail à tous les propriétaires de gem lorsqu'une version de gem est publiée ou supprimée. Nous n'avons reçu aucun e-mail d'assistance de propriétaires de gemmes indiquant que leur gemme a été extraite sans autorisation.
Un audit des modifications apportées aux gemmes au cours des 18 derniers mois n'a trouvé aucun exemple d'utilisation malveillante de cette vulnérabilité. Un audit plus approfondi pour toute utilisation possible de cet exploit n'a trouvé aucune instance de cet exploit utilisé pour prendre en charge une gemme sans autorisation dans l'histoire de RubyGems. Nous ne pouvons pas garantir que cela ne se soit jamais produit, mais cela semble peu probable.
Pour vérifier vos projets, il est recommandé d'analyser l'historique des opérations dans le fichier Gemfile.lock Une activité malveillante s'exprime en présence de modifications portant le même nom et la même version, ou d'un changement de plate-forme (par exemple, lorsqu'un package xxx-1.2.3 .1.2.3 est mis à jour vers xxx-XNUMX-xxx).
Pour éviter l'usurpation d'identité de packages cachés dans les systèmes d'intégration continue ou lors de la publication de projets, il est conseillé aux développeurs d'utiliser Bundler avec les options "--frozen" ou "--deployment" pour confirmer les dépendances.
Enfin, si vous souhaitez en savoir plus à ce sujet , vous trouverez les détails en suivant ce lien.