Le référentiel de packages RubyGems a corrigé une vulnérabilité critique qui permettrait à quiconque de dépublier (« extraire ») certains packages Ruby du référentiel et de republier leurs versions corrompues ou malveillantes avec les mêmes noms de fichiers et numéros de version.
Attribuée CVE-2022-29176, la faille critique existait sur RubyGems.org, qui est l’équivalent Ruby de npmjs.com, et héberge plus de 170 000 packages Ruby (gems) avec près de 100 milliards de téléchargements servis au cours de sa durée de vie.
Un audit initial de RubyGems révèle que la vulnérabilité n’a pas été exploitée au cours des 18 derniers mois pour modifier des gemmes, mais un audit plus approfondi est toujours en cours et les résultats n’ont pas encore été annoncés.
Détourner une gemme : extraire, modifier, republier
Cette semaine, RubyGems a annoncé qu’un bug critique aurait pu permettre à n’importe quel utilisateur de RubyGems.org d’extraire des versions d’une gemme pour lesquelles il n’avait pas d’autorisation et de remplacer le contenu de la gemme par des fichiers plus récents.
Semblable à npm pour les packages NodeJS, RubyGems est un gestionnaire de packages pour le langage de programmation Ruby et fournit un format standardisé pour la distribution des artefacts Ruby finis (appelés « gems »). Le registre RubyGems.org est le service d’hébergement de gemmes de la communauté permettant aux développeurs de publier ou d’installer instantanément des gemmes et d’utiliser un ensemble d’API spécialisées.
Si un acteur malveillant prenait connaissance d’une telle faille, il pourrait discrètement remplacer le contenu de packages Ruby légitimes par un logiciel malveillant, ce qui fait écho aux bibliothèques populaires ua-parser-js, coa et rc de npm qui ont été piratées l’année dernière pour distribuer crypto mineurs et voleurs de mots de passe.
Bien que les incidents de piratage de npm soient dus à des compromis de compte de responsable plutôt qu’à un exploit de vulnérabilité, ils ont fait des ravages car des bibliothèques telles que « ua-parser-js » ont été utilisées par plus d’un millier de projets, y compris ceux utilisés par Facebook, Microsoft, Amazon, Instagram, Google, Slack, Mozilla, Discord, Elastic, Intuit, Reddit et beaucoup plus d’entreprises bien connues.
Dans le cas de Ruby, l’exploitation massive d’un tel exploit pourrait causer des dommages étendus à l’écosystème Ruby et à la sécurité globale de la chaîne d’approvisionnement logicielle.
Pour exploiter la vulnérabilité, explique RubyGems, les conditions suivantes doivent être remplies :
- La gemme ciblée a un ou plusieurs tirets dans son nom, par exemple quelque chose-fournisseur.
- Le mot qui précède le premier tiret représente une gemme contrôlée par l’attaquant qui existe sur RubyGems.org.
- La gemme retirée/modifiée a été créée au cours des 30 derniers jours ou n’a pas été mise à jour depuis plus de 100 jours.
« Par exemple, la gemme fournisseur de quelque chose aurait pu être repris par le propriétaire de la gemme quelque chose« , explique RubyGems.
« Les organisations avec de nombreuses gemmes n’étaient pas vulnérables tant qu’elles possédaient la gemme avec le nom avant le tiret, par exemple la possession de la gemme nom d’organisation protégé toutes les gemmes avec des noms comme orgname-fournisseur. »
Cette vulnérabilité, attribuée CVE-2022-29176, se cachait dans « l’action de retrait » du code RubyGems et a maintenant été corrigée.
À l’heure actuelle, les responsables de RubyGems.org ne pensent pas que la vulnérabilité ait été exploitée, selon les résultats d’un audit qui a analysé les modifications apportées aux gemmes au cours des 18 derniers mois sur la plate-forme.
Mais les propriétaires du registre déclarent qu’un audit plus approfondi est en cours et que ses résultats suivront dans le conseil en sécurité publié pour cette vulnérabilité.
« RubyGems.org envoie un e-mail à tous les propriétaires de gemmes lorsqu’une version de gemme est publiée ou extraite. Nous n’avons reçu aucun e-mail d’assistance des propriétaires de gemmes indiquant que leur gemme a été extraite sans autorisation », indique l’avis.
Utilisateur laursisask a été crédité d’avoir signalé la vulnérabilité via HackerOne.