Une vulnérabilité critique (CVE-2022-29176) a été identifiée dans le dépôt de paquets RubyGems.org, permettant de remplacer des paquets tiers dans le dépôt sans autorisation adéquate en initiant le retrait (yank) d'un paquet légitime et en téléchargeant un autre fichier avec le même nom et le même numéro de version à la place.
Pour qu'une exploitation de la vulnérabilité réussisse, trois conditions doivent être remplies :
- L'attaque ne peut être effectuée que sur des paquets dont le nom contient le symbole de tiret.
- L'attaquant doit être en mesure de publier un paquet gem avec une partie du nom avant le symbole de tiret. Par exemple, si l'attaque est menée sur le paquet « rails-html-sanitizer », l'attaquant doit publier dans le dépôt son propre paquet « rails-html ».
- Le paquet qui est attaqué doit avoir été créé au cours des 30 derniers jours ou ne pas avoir été mis à jour pendant 100 jours.
La vulnérabilité est causée par une erreur dans le gestionnaire d'action « yank », qui traite la partie du nom après le tiret comme un nom de plateforme, permettant de déclencher la suppression de paquets tiers qui correspondent à la partie du nom avant le symbole de tiret. En particulier, dans le code du gestionnaire de l'opération « yank », un appel a été utilisé pour rechercher des paquets : ‘find_by!(full_name: «#{rubygem.name}-#{slug}»)’, alors que le paramètre « slug » était passé par le propriétaire du paquet pour déterminer la version à retirer. Le propriétaire du paquet « rails-html » pouvait indiquer « sanitizer-1.2.3 » au lieu de la version « 1.2.3 », ce qui aurait entraîné l'application de l'opération à un autre paquet « rails-html-sanitizer-1.2.3 ».
Le problème a été découvert par un chercheur en sécurité dans le cadre d'un programme de récompense en cours sur HackerOne pour la recherche de problèmes de sécurité dans des projets open source connus. Le problème a été corrigé dans RubyGems.org le 5 mai et selon les développeurs, ils n'ont pour l'instant pas détecté de traces d'exploitation de la vulnérabilité dans les journaux au cours des 18 derniers mois. Cependant, seul un audit superficiel a été réalisé et des vérifications plus approfondies sont prévues à 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 se manifeste par des modifications préservant le nom et la version ou par un changement de plateforme (par exemple, lorsque le paquet gemname-1.2.3 est mis à jour vers gemname-1.2.3-java). Pour contourner la substitution cachée des paquets dans les systèmes d'intégration continue ou lors de la publication des projets, il est conseillé aux développeurs d'utiliser Bundler avec les options « —frozen » ou « —deployment » pour fixer les dépendances.
Source : opennet.ru
