Ils ont découvert une vulnérabilité dans RubyGems.org qui permettait de remplacer des packages

Récemment, la nouvelle a annoncé que Une vulnérabilité critique a été identifiée dans le référentiel de packages rubygems.org (la vulnérabilité est déjà cataloguée sous CVE-2022-29176), qui permettre sans autorisation valable, remplacer les forfaits des autres dans le référentiel en extrayant un package légitime et en téléchargeant un autre fichier avec le même nom et le même numéro de version à sa place.

Il est mentionné que la vulnérabilité est due à un bogue dans le gestionnaire d'action "yank", qui traite la partie du nom après le trait d'union comme le nom de la plate-forme, ce qui a permis de lancer la suppression des packages externes qui correspondent à la partie du nom jusqu'au trait d'union.

En particulier, dans le code contrôleur de l'opération "yank", l'appel 'find_by!(full_name: "#{rubygem.name}-#{slug}")' était utilisé pour rechercher des packages, tandis que le paramètre "slug" était passé au propriétaire du package 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 mentionné que trois conditions doivent être remplies, afin d'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 HackerOne pour trouver des problèmes de sécurité dans des projets open source connus.

Le problème corrigé sur RubyGems.org le 5 mai et selon les développeurs, n'ont pas encore identifié de traces d'exploitation de la vulnérabilité dans les logs des 18 derniers mois. Dans le même temps, seul un audit superficiel a été réalisé jusqu'à présent, et un audit plus approfondi est prévu à l'avenir.

À 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).

Comme solution contre l'usurpation de packages cachés dans les systèmes d'intégration continue ou lors de la publication de projets, Il est recommandé aux développeurs d'utiliser Bundler avec les options « –gelé » ou « –déploiement » pour confirmer les dépendances.

Enfin, si vous souhaitez en savoir plus, vous pouvez vérifier les détails dans le lien suivant


Le contenu de l'article adhère à nos principes de éthique éditoriale. Pour signaler une erreur, cliquez sur c'est par ici !.

Soyez le premier à commenter

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.

*

*

  1. Responsable des données: Miguel Ángel Gatón
  2. Finalité des données: Contrôle du SPAM, gestion des commentaires.
  3. Légitimation: votre consentement
  4. Communication des données: Les données ne seront pas communiquées à des tiers sauf obligation légale.
  5. Stockage des données: base de données hébergée par Occentus Networks (EU)
  6. Droits: à tout moment, vous pouvez limiter, récupérer et supprimer vos informations.