Kritische Rails-Lücke: Präparierte Uploads schreiben über ImageMagick Dateien auf dem Server

Betroffen ist der Teil von Rails, der Datei-Uploads abwickelt. Speichert eine Anwendung hochgeladene Dateien über den Disk-Service von Active Storage auf der Serverplatte, kann ein Angreifer zusätzlich jede Datei lesen, auf die die Anwendung Zugriff hat. Dazu gehören nach Angaben von Rails typischerweise der secret_key_base sowie die Zugangsdaten der Anwendung für andere Systeme. Deren Auslesen kann wiederum Codeausführung aus der Ferne oder seitliche Bewegung in diese Systeme ermöglichen.

Technisch liegt die Ursache darin, dass ImageMagick anhand des Dateiinhalts einen Formathandler — in der ImageMagick-Terminologie ein „Coder" — auswählt. Manche Coder wirken nicht auf das Bild selbst, sondern auf andere Dateien, die im Bild benannt sind. Active Storage schränkte nicht ein, welche Coder ein Upload nutzen darf; die einzige Grenze war die ImageMagick-Policy des jeweiligen Servers.

Der ImageMagick-Analyzer von Active Storage läuft bereits beim Anhängen einer Datei. Das Anhängen allein genügt, um die Lücke zu erreichen: Die Anwendung muss weder eine Variante (eine transformierte Kopie des Bildes) noch eine Vorschau erzeugen noch analyze aufrufen. Dem Commit, der die Lücke behebt, zufolge erreichte eine hochgeladene SVG-Datei über diesen Analyzer den MSL-Coder von ImageMagick — einen Skripting-Coder, der die in seinem Skript benannten Dateien liest und schreibt. Rails erklärte, es sei eine Angriffskette gemeldet worden, man gehe aber „nicht davon aus, dass sie die einzige existierende ist". Ob die Lücke ausgenutzt wurde, sagt der Sicherheitshinweis nicht. Gemeldet wurde sie über HackerOne von RyotaK, einem Forscher bei GMO Flatt Security.

Betroffen ist eine Anwendung nur, wenn alle drei folgenden Bedingungen zutreffen:

• Sie nutzt ImageMagick für die Bildverarbeitung in Active Storage, also die Einstellung config.active_storage.variant_processor = :mini_magick — Standard für Anwendungen mit load_defaults 6.1 oder älter.
• Ihre ImageMagick-Sicherheitspolicy blockiert die beteiligten Coder nicht bereits. Die von Debian und Ubuntu ausgelieferten Policies tun das laut Rails nicht.
• Sie nimmt Datei-Uploads von nicht vertrauenswürdigen Nutzern an.

Für die erste Bedingung ist config.active_storage.variant_processor maßgeblich. Ist der Wert nicht gesetzt, hängt die Vorgabe von load_defaults ab: :mini_magick vor 7.0, :vips ab 7.0. Dieselbe Einstellung entscheidet auch, welche Bibliothek Uploads analysiert, nicht nur, welche Varianten erzeugt. Betroffen sind alle Active-Storage-Versionen vor 8.0.5.2 sowie 8.1-Versionen vor 8.1.4.1. Für Release-Serien älter als 8.0 gibt es keinen Support mehr und keine korrigierten Versionen.

Im Juli hatte Rails bereits eine andere kritische Active-Storage-Lücke behoben, CVE-2026-66066, die Anwendungen mit libvips statt ImageMagick betraf. ImageMagick-Anwendungen waren von jenem Angriffsweg nicht betroffen, von diesem können sie es sein.

Dieselben Releases schließen eine zweite Active-Storage-Lücke, GHSA-v924-7rp8-4mxh, die Rails mit CVSS 8.8 als hoch einstuft: Active Storage übergab Uploads an ImageMagick und FFmpeg unter temporären Dateinamen, die die Endung der hochgeladenen Datei beibehielten. Beide Werkzeuge können den Decoder anhand der Endung wählen, wenn der Dateiinhalt das Format nicht erkennen lässt. Ein Angreifer, der Dateiname und deklarierten Content-Type bestimmt, konnte so den verarbeitenden Decoder wählen.

Rails empfiehlt dringend, so bald wie möglich zu aktualisieren. Die beiden Releases beheben insgesamt 21 Sicherheitsprobleme. Die korrigierten Versionen liefern eine ImageMagick-Sicherheitspolicy mit. MiniMagick ist das Ruby-Gem, über das Active Storage ImageMagick aufruft; in der Standardkonfiguration gilt die Policy für jeden darüber ausgeführten ImageMagick-Befehl, nicht nur für Befehle aus Active Storage. Blockiert werden:

• der MSL-Coder,
• Coder, die andere Dateien als das Bild lesen oder löschen,
• Coder, die entfernte oder lokale Referenzen abrufen oder auf einem Bildschirm anzeigen,
• jeder auf Ghostscript basierende Coder samt gs-Delegat,
• die @filename-Indirektion.

Anwendungen auf :mini_magick benötigen zusätzlich mini_magick 5.1 oder neuer, sonst brechen sie beim Start mit einem Fehler ab. Rails 8.0 erhält gemäß Maintenance-Policy nur noch bis zum 7. November 2026 Sicherheitsfixes.

Ob die neue Policy tatsächlich geladen wird, lässt sich mit bin/rails runner ‘puts MiniMagick.identify { |i| i.list “policy” }’ prüfen, wie im Active-Storage-Leitfaden beschrieben. Die mitgelieferte Policy erreicht eine Anwendung nicht, wenn diese nach dem Start MiniMagick.cli_env ersetzt, die Umgebung über MiniMagick.cli_prefix leert oder eine eigene MiniMagick::Shell installiert — dann müssen die Regeln in die System-Policy von ImageMagick. Anwendungen, die GraphicsMagick nutzen, profitieren gar nicht von der mitgelieferten Policy, da GraphicsMagick keine ImageMagick-Policies liest.

Zu prüfen ist außerdem die eigene ImageMagick-Policy des Servers: Die mitgelieferte Policy ergänzt sie, ersetzt sie aber nicht. Eine dortige Regel, die einen Coder erlaubt — auch per Platzhalter wie pattern="*" —, hebt die Sperre der mitgelieferten Policy für diesen Coder auf. Rendert eine Anwendung PDF- oder PostScript-Dateien über ImageMagick, müssen der gs-Delegat und die davon genutzten Coder in der policy.xml des Servers wieder freigegeben werden.

Wer nicht aktualisieren kann, kann die Regeln der mitgelieferten Datei activestorage/lib/active_storage/image_magick/policy.xml in die System-Policy von ImageMagick übernehmen, etwa /etc/ImageMagick-7/policy.xml. Mindestens der MSL-Coder, die Ghostscript-Coder und der gs-Delegat sollten blockiert werden. Rails hat den Fix zusätzlich als Patches für 8.1 und 8.0 veröffentlicht. Anwendungen auf Serien älter als 8.0 können diesen Behelf nutzen oder auf 8.0 oder neuer wechseln. Die Workarounds für die zweite Lücke ändern nur den Umgang mit FFmpeg und decken ImageMagick nicht ab.

Speichert eine Anwendung Anhänge über den Disk-Service, sollten der secret_key_base und jedes weitere Geheimnis gewechselt werden, das der Anwendungsprozess lesen kann: der Master Key, sämtliche Inhalte von config/credentials.yml.enc, Storage- und Datenbank-Zugangsdaten sowie Tokens von Drittanbietern. Ein offengelegtes Geheimnis sollte nicht als Rückfallwert erhalten bleiben. Wie sich prüfen lässt, ob eine Anwendung bereits angegriffen wurde, erläutert der Sicherheitshinweis nicht.