Une vulnérabilité critique (CVE-2022-29176) a été identifiée dans le référentiel de packages RubyGems.org, qui permet, sans autorisation appropriée, de remplacer les packages de certaines autres personnes dans le référentiel en lançant un retrait d'un package légitime et en le chargeant à sa place. un autre fichier avec le même nom et le même numéro de version.
Pour réussir à exploiter la vulnérabilité, trois conditions doivent être remplies :
- L'attaque ne peut être effectuée que sur les paquets comportant un trait d'union dans leur nom.
- Un attaquant doit être capable de placer un package de gemmes avec une partie du nom avant le trait d'union. Par exemple, si l'attaque porte sur le package « rails-html-sanitizer », l'attaquant doit placer son propre package « rails-html » dans le référentiel.
- Le package attaqué doit avoir été créé au cours des 30 derniers jours ou n'avoir pas été mis à jour depuis 100 jours.
La vulnérabilité est causée par une erreur dans le gestionnaire d'action « yank », qui interprète la partie du nom après le trait d'union comme le nom de la plateforme, ce qui a permis d'initier la suppression des packages étrangers correspondant à la partie du nom. avant le trait d'union. En particulier, dans le code du gestionnaire "yank", l'appel 'find_by!(full_name: "#{rubygem.name}-#{slug}")" était utilisé pour rechercher des packages, tandis que le paramètre "slug" était passé par le propriétaire du package pour déterminer la version à supprimer. Le propriétaire du package "rails-html" pourrait 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 package "rails-html-sanitizer-1.2.3" de quelqu'un d'autre. ".
Le problème a été identifié par un chercheur en sécurité dans le cadre du programme de primes de HackerOne visant à détecter des problèmes de sécurité dans des projets open source connus. Le problème a été résolu dans RubyGems.org le 5 mai et selon les développeurs, ils n'ont encore identifié aucune trace d'exploitation de la vulnérabilité dans les logs au cours 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.
Pour vérifier vos projets, il est recommandé d'analyser l'historique des opérations dans le fichier Gemfile.lock ; l'activité malveillante s'exprime en présence de changements avec conservation du nom et de la version ou d'un changement de plateforme (par exemple, lorsque le gemname -1.2.3 est mis à jour vers gemname-1.2.3-java). Comme solution de contournement pour se protéger contre la substitution 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 corriger les dépendances.
Source: opennet.ru