Rails : un SVG écrit des fichiers via ImageMagick

Ce qui se passe

Le projet Rails a corrigé une faille critique d'Active Storage, la partie du framework qui gère les fichiers envoyés par les utilisateurs. Identifiant : GHSA-f3w6-w445-fwh9, score CVSS 9.8, pas encore de CVE. Un attaquant sans compte qui téléverse un fichier forgé peut faire écrire des fichiers arbitraires sur le serveur, si l'application traite ses images avec ImageMagick. Quand les fichiers sont stockés par le service Disk (le disque du serveur), il peut aussi lire tout fichier que l'application lit : typiquement secret_key_base et les identifiants vers d'autres systèmes, ce qui ouvre la voie à l'exécution de code ou au rebond. Le défaut a été signalé via HackerOne par RyotaK, de GMO Flatt Security.

Le mécanisme

ImageMagick choisit un décodeur (un coder) d'après le contenu du fichier, pas d'après son nom. Certains décodeurs agissent sur d'autres fichiers cités dans l'image. Active Storage ne limitait pas les décodeurs permis : la seule barrière était la politique ImageMagick du serveur.

Le commit de correction montre le chemin : un SVG envoyé atteint, par l'analyseur d'Active Storage, le décodeur MSL, un langage de script qui lit et écrit les fichiers nommés dans son script. L'analyseur tourne dès que le fichier est attaché : l'application n'a besoin ni de créer une variante, ni un aperçu, ni d'appeler analyze.

Êtes-vous concerné ?

Il faut que les trois conditions soient réunies :

1. Le traitement d'images passe par ImageMagick : config.active_storage.variant_processor = :mini_magick. Sans réglage explicite, c'est le défaut des applications en load_defaults 6.1 ou plus ancien ; à partir de 7.0, le défaut est :vips. Ce réglage décide aussi quelle bibliothèque analyse les envois.
2. La politique ImageMagick ne bloque pas ces décodeurs. Selon Rails, celles livrées par Debian et Ubuntu ne les bloquent pas.
3. L'application accepte des fichiers d'utilisateurs non fiables.

Toutes les versions d'Active Storage antérieures à 8.0.5.2 sont touchées, ainsi que les 8.1 avant 8.1.4.1. Les séries antérieures à 8.0 ne sont plus maintenues : aucune version corrigée n'y sera publiée.

Que faire

• Passer en 8.1.4.1 ou 8.0.5.2. Avec :mini_magick, il faut aussi mini_magick 5.1 ou plus récent, sinon l'application échoue au démarrage. Rails 8.0 ne reçoit des correctifs de sécurité que jusqu'au 7 novembre 2026.
• Vérifier que la politique livrée est bien chargée :

bin/rails runner 'puts MiniMagick.identify { |i| i.list "policy" }'

• Attention aux cas où elle ne s'applique pas : une application qui remplace MiniMagick.cli_env après le démarrage, vide l'environnement avec MiniMagick.cli_prefix ou installe son propre MiniMagick::Shell doit écrire les règles dans la politique système. GraphicsMagick ne lit pas les politiques ImageMagick et n'est donc pas protégé.
• La politique livrée s'ajoute à celle du serveur sans la remplacer : une règle qui autorise un décodeur, y compris par un joker comme pattern="*", l'emporte sur le blocage.
• Si l'application génère des PDF ou PostScript via ImageMagick, il faudra rouvrir le délégué gs et ses décodeurs dans policy.xml.
• Impossible de mettre à jour tout de suite ? Copier les règles de activestorage/lib/active_storage/image_magick/policy.xml dans la politique système (par exemple /etc/ImageMagick-7/policy.xml). Au minimum : bloquer MSL, les décodeurs Ghostscript et le délégué gs. Exemple de syntaxe pour MSL :

<policy domain="coder" rights="none" pattern="MSL" />

• Stockage Disk : changer secret_key_base et tous les secrets lisibles par l'application (clé maîtresse, contenu de config/credentials.yml.enc, accès aux bases et au stockage, jetons tiers). Ne gardez pas un secret exposé en secours.

Ce que l'on ne sait pas

Rails dit qu'une seule chaîne d'attaque lui a été signalée, sans supposer qu'elle soit la seule. L'avis ne dit pas si la faille est exploitée ni comment savoir si une application a déjà été visée. Les mêmes versions corrigent un second défaut, GHSA-v924-7rp8-4mxh (8.8, élevée) : Active Storage passait les envois à ImageMagick et FFmpeg sous des noms temporaires qui gardaient l'extension fournie, laissant l'attaquant choisir le décodeur. Au total, ces deux versions corrigent 21 problèmes de sécurité.

Une extrapolation de cette fiche, que la source ne formule pas : toute application qui confie à ImageMagick des fichiers d'inconnus, en PHP avec Imagick ou en ligne de commande, relève de la même question de politique système.

Source : The Hacker News, qui cite l'avis GHSA-f3w6-w445-fwh9. Source en anglais.