Kritische Rails-Schwachstelle ermöglicht Dateischreiben über ImageMagick-Uploads

Eine schwerwiegende Sicherheitslücke in Ruby on Rails ermöglicht es nicht authentifizierten Angreifern, beliebige Dateien auf einem Server zu schreiben, indem sie speziell präparierte Bilder hochladen. Das Rails-Projekt hat am 4. November 2026 Korrekturen in den Versionen 8.1.4.1 und 8.0.5.2 veröffentlicht, um einen Fehler in der Active Storage-Komponente bei Verwendung mit ImageMagick zu beheben.

Was passiert ist

Die Schwachstelle liegt darin, wie Active Storage Datei-Uploads verarbeitet, wenn es für die Bildbearbeitung auf ImageMagick konfiguriert ist. Wenn eine Anwendung einen Datei-Upload akzeptiert, führt Active Storage einen Analyzer aus, um den Dateityp zu bestimmen. Dieser Prozess veranlasst ImageMagick, den Inhalt zu untersuchen, wobei ein Format-Handler, auch als Coder bezeichnet, basierend auf dem Inhalt der Datei ausgewählt wird. Einige dieser Coders sind so konzipiert, dass sie auf externe Dateien wirken, die innerhalb der Bilddaten referenziert werden, anstatt nur das Bild selbst zu verarbeiten.

In diesem speziellen Fall kann ein Angreifer eine SVG-Datei hochladen, die den MSL-Coder aufruft, ein Skriptformat, das in der Lage ist, Dateien zu lesen und zu schreiben, die im Skript spezifiziert sind. Da Active Storage nicht einschränkte, welche Coders während der Analyse verwendet werden dürfen, wurde die Standard-ImageMagick-Richtlinie des Servers zur einzigen Verteidigungslinie. Auf vielen Systemen, einschließlich solcher, die Debian oder Ubuntu ausführen, blockiert die Standardrichtlinie diese gefährlichen Coders nicht. Folglich reicht es aus, eine bösartige Datei anzuhängen, um die Schwachstelle auszunutzen, ohne dass Vorschauen generiert oder das Bild transformiert werden muss.

Wenn die Anwendung Dateien unter Verwendung des Disk-Dienstes speichert, kann der Angreifer auch jede Datei lesen, auf die die Anwendung Zugriffsrechte hat. Dies umfasst in der Regel sensible Anmeldedaten wie secret_key_base, Datenbank-Passwörter und API-Tokens von Drittanbietern. Der Zugriff auf diese Geheimnisse kann zu Remote Code Execution oder lateraler Bewegung in andere verbundene Systeme führen. Das Rails-Team bewertete diese Schwachstelle mit 9,8 von 10 Punkten auf der CVSS-Skala, was einer nahezu maximalen Schweregradstufe entspricht.

Wichtige Details

• Die Schwachstelle wird als GHSA-f3w6-w445-fwh9 verfolgt und betrifft Rails-Versionen vor 8.0.5.2 und 8.1.4.1.
• Sie erfordert, dass die Anwendung config.active_storage.variant_processor = :mini_magick verwendet, was der Standard für ältere Rails-Konfigurationen ist.
• Der Angriffsvektor beinhaltet das Hochladen einer präparierten Datei, wie z. B. einer SVG-Datei, die den MSL-Coder von ImageMagick während der Anhangsanalyse-Phase auslöst.
• Apps, die den Disk-Dienst für die Speicherung verwenden, sind einem höheren Risiko ausgesetzt, da Angreifer sensible Konfigurationsdateien und Geheimnisse vom Server lesen können.
• Der Fix führt eine strenge ImageMagick-Sicherheitsrichtlinie ein, die gefährliche Coders wie MSL, Ghostscript und solche, die Datei-Indirektion ermöglichen, blockiert.
• Ein zweiter Fehler mit hohem Schweregrad, GHSA-v924-7rp8-4mxh, wurde ebenfalls in diesen Releases behoben; er betrifft, wie Dateiendungen die Decoder-Auswahl in FFmpeg und ImageMagick beeinflussen.

Hintergrund

Active Storage ist das Standard-Framework in Rails zur Verwaltung von Dateianhängen. Es delegiert Aufgaben der Bildverarbeitung an externe Bibliotheken, üblicherweise ImageMagick oder libvips. ImageMagick ist ein leistungsstarkes Tool, das Hunderte von Bildformaten unterstützt, wobei jedes von einem spezifischen Coder gehandhabt wird. Während diese Flexibilität für Entwickler nützlich ist, birgt sie Sicherheitsrisiken, wenn bestimmte Coders Skripte ausführen oder auf das Dateisystem jenseits der unmittelbaren Bilddatei zugreifen dürfen.

Sicherheitsrichtlinien in ImageMagick sind in XML-Dateien definiert, die festlegen, welche Operationen und Coders zulässig sind. Historisch gesehen lieferten viele Linux-Distributionen permissive Richtlinien aus, um die Kompatibilität mit verschiedenen Workflows sicherzustellen. Diese Schwachstelle verdeutlicht die Gefahr, sich bei der Anwendungssicherheit auf systemweite Standardeinstellungen zu verlassen, insbesondere bei der Verarbeitung nicht vertrauenswürdiger Benutzereingaben. Der aktuelle Fix verschiebt die Verantwortung auf das Anwendungsframework, indem eine restriktive Richtlinie direkt mit Rails gebündelt wird.

Warum das wichtig ist

Für Teams, die selbst gehostete Rails-Anwendungen betreiben, stellt diese Schwachstelle eine direkte Bedrohung für die Integrität der Infrastruktur dar. Im Gegensatz zu einigen Bugs, die komplexe Bedingungen für die Ausnutzung erfordern, wird dieser durch den grundlegenden Akt des Datei-Hochladens ausgelöst. Wenn Ihre Anwendung Uploads von öffentlichen Benutzern oder sogar internem Personal akzeptiert, ist sie potenziell exponiert. Die Fähigkeit eines Angreifers, Dateien zu schreiben, bedeutet, dass er Hintertüren platzieren, Anwendungscode modifizieren oder Daten exfiltrieren könnte, indem er Konfigurationsdateien liest.

Die Auswirkungen werden für Anwendungen, die den Disk-Dienst nutzen, noch gravierender, da die Offenlegung von Geheimnissen wie secret_key_base das gesamte Sicherheitsmodell der Anwendung kompromittiert. Sobald ein Angreifer diese Schlüssel besitzt, kann er Session-Cookies fälschen, gespeicherte Anmeldedaten entschlüsseln und Benutzer impersonieren. Dies macht eine sofortige Behebung kritisch, da das Zeitfenster für eine Ausnutzung groß und das potenzielle Schadensausmaß umfangreich ist. Darüber hinaus erhalten ältere Rails-Versionen keine Sicherheitspatches mehr, was Teams auf Legacy-Systemen zwingt, alternative Mitigationsstrategien zu finden.

Was Sie tun können

• Führen Sie sofort ein Upgrade auf Rails 8.1.4.1 oder 8.0.5.2 durch und stellen Sie sicher, dass die mini_magick-Gem-Version 5.1 oder neuer installiert ist.
• Überprüfen Sie, ob die neue ImageMagick-Richtlinie aktiv ist, indem Sie bin/rails runner 'puts MiniMagick.identify { |i| i.list "policy" }' ausführen.
• Wenn Sie kein Upgrade durchführen können, kopieren Sie manuell die restriktive Richtlinie aus activestorage/lib/active_storage/image_magick/policy.xml in die ImageMagick-Richtliniendatei Ihres Systems.
• Rotieren Sie alle Geheimnisse unverzüglich, wenn Ihre App den Disk-Dienst verwendet, einschließlich secret_key_base, Datenbank-Anmeldedaten und API-Tokens, da diese möglicherweise offengelegt wurden.
• Prüfen Sie auf benutzerdefinierte ImageMagick-Konfigurationen, die die neuen Einschränkungen außer Kraft setzen könnten, wie z. B. Wildcards in policy.xml, die blockierte Coders wieder aktivieren.
• Erwägen Sie eine Migration zu libvips, wenn möglich, da dieses nicht von dieser spezifischen, ImageMagick-bezogenen Schwachstellenkette betroffen ist.