Vulnérabilité critique de Rails permettant l'écriture de fichiers via les téléchargements ImageMagick
Les versions de Ruby on Rails antérieures à 8.0.5.2 et 8.1.4.1 contiennent une vulnérabilité critique dans Active Storage qui permet aux attaquants d'écrire des fichiers via des téléchargements d'images ImageMagick spécialement conçus.
Traduit automatiquement depuis l’original en anglais.
Une faille de sécurité grave dans Ruby on Rails permet à des attaquants non authentifiés d'écrire des fichiers arbitraires sur un serveur en téléchargeant des images spécialement conçues. Le projet Rails a publié des correctifs dans les versions 8.1.4.1 et 8.0.5.2 le 4 novembre 2026, corrigeant une faille dans le composant Active Storage lorsqu'il est utilisé avec ImageMagick.
Ce qui s'est passé
La vulnérabilité réside dans la manière dont Active Storage gère les téléchargements de fichiers lorsqu'il est configuré pour utiliser ImageMagick pour le traitement d'images. Lorsqu'une application accepte un téléchargement de fichier, Active Storage exécute un analyseur pour déterminer le type de fichier. Ce processus déclenche l'inspection du contenu par ImageMagick, qui sélectionne un gestionnaire de format, appelé coder, en fonction de ce qu'il trouve dans le fichier. Certains de ces coders sont conçus pour agir sur des fichiers externes référencés dans les données de l'image plutôt que sur l'image elle-même.
Dans ce cas précis, un attaquant peut télécharger un fichier SVG qui invoque le coder MSL, un format de script capable de lire et d'écrire des fichiers spécifiés dans son script. Comme Active Storage ne restreignait pas les coders pouvant être utilisés lors de l'analyse, la politique ImageMagick par défaut du serveur constituait la seule ligne de défense. Sur de nombreux systèmes, y compris ceux exécutant Debian ou Ubuntu, la politique par défaut ne bloque pas ces coders dangereux. Par conséquent, il suffit de joindre un fichier malveillant pour exploiter la faille, sans avoir besoin de générer des aperçus ni de transformer l'image.
Si l'application stocke les fichiers à l'aide du service Disk, l'attaquant peut également lire tout fichier auquel l'application a accès. Cela inclut généralement des identifiants sensibles tels que secret_key_base, les mots de passe de base de données et les jetons d'API tiers. L'accès à ces secrets peut entraîner l'exécution de code à distance ou un mouvement latéral vers d'autres systèmes connectés. L'équipe Rails a noté cette vulnérabilité 9,8 sur 10 sur l'échelle CVSS, indiquant une sévérité proche du maximum.
Détails clés
- La vulnérabilité est suivie sous la référence GHSA-f3w6-w445-fwh9 et affecte les versions de Rails antérieures à 8.0.5.2 et 8.1.4.1.
- Elle nécessite que l'application utilise
config.active_storage.variant_processor = :mini_magick, qui est la valeur par défaut pour les configurations Rails plus anciennes. - Le vecteur d'attaque consiste à télécharger un fichier conçu à cet effet, comme un SVG, qui déclenche le coder MSL d'ImageMagick lors de la phase d'analyse de la pièce jointe.
- Les applications utilisant le service Disk pour le stockage sont à risque plus élevé car les attaquants peuvent lire des fichiers de configuration sensibles et des secrets depuis le serveur.
- Le correctif introduit une politique de sécurité stricte pour ImageMagick qui bloque les coders dangereux comme MSL, Ghostscript et ceux autorisant l'indirection de fichiers.
- Une seconde faille de haute sévérité, GHSA-v924-7rp8-4mxh, a également été corrigée dans ces versions, concernant la manière dont les extensions de fichiers influencent la sélection du décodeur dans FFmpeg et ImageMagick.
Contexte
Active Storage est le framework standard de Rails pour la gestion des pièces jointes. Il délègue les tâches de traitement d'images à des bibliothèques externes, couramment ImageMagick ou libvips. ImageMagick est un outil puissant qui prend en charge des centaines de formats d'image, chacun étant traité par un coder spécifique. Bien que cette flexibilité soit utile pour les développeurs, elle introduit des risques de sécurité si certains coders sont autorisés à exécuter des scripts ou à accéder au système de fichiers au-delà du fichier image immédiat.
Les politiques de sécurité dans ImageMagick sont définies dans des fichiers XML qui spécifient quelles opérations et quels coders sont autorisés. Historiquement, de nombreuses distributions Linux étaient livrées avec des politiques permissives pour assurer la compatibilité avec divers flux de travail. Cette vulnérabilité met en évidence le danger de se fier aux valeurs par défaut du système pour la sécurité des applications, surtout lors du traitement d'entrées utilisateur non fiables. Le correctif récent transfère la responsabilité au framework applicatif en intégrant directement une politique restrictive avec Rails.
Pourquoi c'est important
Pour les équipes exploitant des applications Rails auto-hébergées, cette vulnérabilité représente une menace directe pour l'intégrité de l'infrastructure. Contrairement à certains bugs nécessitant des conditions complexes pour être exploités, celui-ci est déclenché par le simple acte de télécharger un fichier. Si votre application accepte les téléchargements d'utilisateurs publics ou même de personnel interne, elle est potentiellement exposée. La capacité d'un attaquant à écrire des fichiers signifie qu'il pourrait installer des backdoors, modifier le code de l'application ou exfiltrer des données en lisant les fichiers de configuration.
L'impact est aggravé pour les applications utilisant le service Disk, car l'exposition de secrets comme secret_key_base compromet le modèle de sécurité de l'application entière. Une fois que l'attaquant possède ces clés, il peut falsifier les cookies de session, déchiffrer les identifiants stockés et usurper l'identité des utilisateurs. Cela rend la remédiation immédiate cruciale, car la fenêtre d'exploitation est large et les dommages potentiels étendus. De plus, les anciennes versions de Rails ne reçoivent plus de correctifs de sécurité, obligeant les équipes sur des systèmes hérités à trouver des stratégies d'atténuation alternatives.
Que pouvez-vous faire
- Mettez à niveau immédiatement vers Rails 8.1.4.1 ou 8.0.5.2, et assurez-vous que la version 5.1 ou ultérieure du gem mini_magick est installée.
- Vérifiez que la nouvelle politique ImageMagick est active en exécutant
bin/rails runner 'puts MiniMagick.identify { |i| i.list "policy" }'. - Si vous ne pouvez pas mettre à niveau, copiez manuellement la politique restrictive de
activestorage/lib/active_storage/image_magick/policy.xmlvers le fichier de politique ImageMagick de votre système. - Faites tourner tous les secrets immédiatement si votre application utilise le service Disk, y compris
secret_key_base, les identifiants de base de données et les jetons d'API, car ils ont pu être exposés. - Vérifiez les configurations personnalisées d'ImageMagick qui pourraient outrepasser les nouvelles restrictions, telles que les caractères génériques dans
policy.xmlqui réactivent les coders bloqués. - Envisagez de migrer vers libvips si possible, car il n'est pas affecté par cette chaîne de vulnérabilité spécifique liée à ImageMagick.



