Une image piégée permet d'écrire des fichiers sur les serveurs Ruby on Rails

Ruby on Rails, le framework web qui fait tourner de nombreuses boutiques en ligne, produits SaaS et start-up, a corrigé une faille critique : un attaquant sans aucun compte pouvait écrire des fichiers arbitraires sur le serveur en envoyant simplement une image piégée. Le bug se trouve dans Active Storage, le composant de Rails qui gère l'envoi de fichiers, et touche les applications qui traitent les images avec ImageMagick. Il est noté 9,8 sur 10, selon le bulletin de sécurité de Rails. Le correctif est sorti le 4 novembre dans Rails 8.0.5.2 et 8.1.4.1.

Comment un seul envoi compromet le serveur

ImageMagick choisit comment lire un fichier d'après son contenu, pas d'après son nom. Certains de ses « codeurs » ne se contentent pas de décoder une image : ils suivent des instructions contenues dans le fichier et lisent ou écrivent d'autres fichiers sur le disque. Active Storage n'en restreignait aucun et lance son analyseur ImageMagick dès qu'un fichier est attaché. « Attacher le fichier envoyé suffit ; aucun appel à variant, preview ou analyze n'est nécessaire », indique le bulletin.

Si l'application stocke les fichiers sur le disque local (service Disk), l'attaquant peut aussi lire tout fichier accessible à l'application. Parmi eux figurent généralement secret_key_base et les identifiants des bases de données, du stockage cloud et des services tiers. Avec eux, avertit le bulletin, un attaquant peut aller jusqu'à l'exécution de code à distance ou rebondir vers les systèmes connectés. La faille a été signalée par le chercheur ryotak via HackerOne. Rails précise qu'une chaîne d'attaque lui a été rapportée, « mais nous ne supposons pas que ce soit la seule ».

Quelles applications sont touchées

Une application est vulnérable si les trois conditions sont réunies :

• ImageMagick traite les images. C'est le processeur de variantes :mini_magick, par défaut dans les applications configurées avec load_defaults 6.1 ou antérieur. Depuis Rails 7.0, les nouvelles applications utilisent libvips : elles ne sont exposées que si quelqu'un les a repassées sur ImageMagick.
• ImageMagick tourne sans politique stricte. Les politiques fournies par Debian et Ubuntu ne bloquent pas les codeurs en cause.
• Des inconnus peuvent envoyer des fichiers : avatars, photos de produits, pièces jointes aux tickets d'assistance.

Sont concernées les versions d'activestorage antérieures à 8.0.5.2 et la branche 8.1 avant 8.1.4.1. Les anciennes branches n'auront pas de correctif : l'équipe Rails indique que les versions précédentes ne sont plus prises en charge et recommande de passer au moins à la série 8.0, dont le support de sécurité s'arrête pourtant le 7 novembre 2026. La même version corrige 20 autres problèmes de sécurité, dont quatre jugés graves, parmi lesquels un bug distinct dans les aperçus vidéo qui pouvait mener à l'exécution de code via FFmpeg.

Le bulletin ne mentionne aucune attaque en conditions réelles. Mais une fois le correctif public, les attaquants peuvent comparer l'ancien et le nouveau code pour trouver la faille : chaque jour sans mise à jour augmente donc le risque.

Ce que doivent faire les développeurs

• Passez à Rails 8.0.5.2 ou 8.1.4.1. Si vous utilisez mini_magick, il vous faut aussi mini_magick 5.1 ou plus récent, sinon l'application plantera au démarrage.
• Si vous ne pouvez pas mettre à jour tout de suite, copiez la politique ImageMagick de la version corrigée dans le policy.xml du système. Au minimum, interdisez le codeur MSL, les codeurs Ghostscript et le délégué gs.
• Si les fichiers étaient stockés avec le service Disk, changez secret_key_base, la clé maître, tout le contenu de credentials.yml.enc, les mots de passe des bases et du stockage, ainsi que les jetons tiers. Le bulletin conseille de ne pas garder l'ancien secret en solution de repli.
• Si votre application génère des PDF ou du PostScript via ImageMagick, réautorisez uniquement les codeurs nécessaires après avoir appliqué la politique.

Les utilisateurs de sites sous Rails n'ont rien à installer. Le risque pour eux, c'est la fuite des données clients d'une boutique ou d'un service non corrigé, et cela dépend de la rapidité de ses développeurs.