Präpariertes Bild lässt Angreifer Dateien auf Ruby-on-Rails-Server schreiben

Ruby on Rails, das Web-Framework hinter vielen Onlineshops, SaaS-Produkten und Start-ups, hat eine kritische Lücke geschlossen: Ein Angreifer ohne Konto konnte beliebige Dateien auf den Server schreiben, indem er einfach ein präpariertes Bild hochlud. Der Fehler steckt in Active Storage, der Rails-Komponente für Datei-Uploads, und betrifft Apps, die Bilder mit ImageMagick verarbeiten. Er wird mit 9,8 von 10 bewertet, heißt es im Sicherheitshinweis von Rails. Die Korrektur erschien am 4. November in Rails 8.0.5.2 und 8.1.4.1.

Wie ein Upload den Server knackt

ImageMagick entscheidet anhand des Inhalts, nicht des Namens, wie eine Datei gelesen wird. Manche seiner „Coder“ dekodieren nicht nur ein Bild, sondern folgen Anweisungen in der Datei und lesen oder schreiben andere Dateien auf der Festplatte. Active Storage schränkte keinen davon ein und startet den ImageMagick-Analyzer, sobald eine Datei angehängt wird. „Das Anhängen des Uploads genügt; kein Variant-, Preview- oder analyze-Aufruf ist nötig“, heißt es im Hinweis.

Speichert eine App Uploads auf der lokalen Festplatte (Disk-Service), kann der Angreifer zudem jede Datei lesen, die die App lesen darf. Dazu gehören meist secret_key_base und Zugangsdaten für Datenbanken, Cloud-Speicher und Drittdienste. Damit, warnt der Hinweis, kann ein Angreifer bis zur Ausführung von Code aus der Ferne gelangen oder auf verbundene Systeme übergreifen. Gemeldet hat die Lücke der HackerOne-Forscher ryotak. Rails zufolge wurde eine Angriffskette gemeldet, „aber wir gehen nicht davon aus, dass sie die einzige ist“.

Welche Apps betroffen sind

Eine App ist verwundbar, wenn alle drei Bedingungen zutreffen:

• ImageMagick verarbeitet Bilder. Das ist der Variant-Prozessor :mini_magick, Standard bei Apps mit load_defaults 6.1 oder älter. Seit Rails 7.0 nutzen neue Apps libvips; sie sind nur betroffen, wenn jemand sie auf ImageMagick zurückgestellt hat.
• ImageMagick läuft ohne strenge Richtlinie. Die Richtlinien aus den Debian- und Ubuntu-Paketen blockieren die betreffenden Coder nicht.
• Fremde können Dateien hochladen: Avatare, Produktfotos, Anhänge an Support-Tickets.

Betroffen sind activestorage vor 8.0.5.2 und 8.1 vor 8.1.4.1. Ältere Zweige bekommen keine Korrektur: Das Rails-Team schreibt, frühere Versionen würden nicht mehr unterstützt, und empfiehlt mindestens die 8.0-Reihe, deren Sicherheitsunterstützung allerdings am 7. November 2026 endet. Dasselbe Release schließt 20 weitere Sicherheitsprobleme, vier davon als hoch eingestuft, darunter einen separaten Fehler in Video-Vorschauen, der über FFmpeg zur Codeausführung führen konnte.

Von Angriffen in freier Wildbahn sagt der Hinweis nichts. Doch sobald ein Fix öffentlich ist, können Angreifer alten und neuen Code vergleichen und so die Lücke finden. Jeder Tag ohne Update erhöht also das Risiko.

Was Entwickler tun sollten

• Auf Rails 8.0.5.2 oder 8.1.4.1 aktualisieren. Wer mini_magick nutzt, braucht außerdem mini_magick 5.1 oder neuer, sonst startet die App nicht.
• Geht das Update nicht sofort, die ImageMagick-Richtlinie aus dem korrigierten Release in die systemweite policy.xml übernehmen. Mindestens den MSL-Coder, die Ghostscript-Coder und den gs-Delegate sperren.
• Lagen Uploads im Disk-Service, secret_key_base, den Master-Key, alles in credentials.yml.enc, Datenbank- und Speicherpasswörter sowie Drittanbieter-Token austauschen. Laut Hinweis das alte Geheimnis nicht als Fallback behalten.
• Rendert die App PDF oder PostScript über ImageMagick, nach dem Einspielen der Richtlinie nur die nötigen Coder wieder freigeben.

Nutzer von Rails-Websites müssen nichts installieren. Für sie besteht das Risiko, dass Kundendaten aus einem nicht aktualisierten Shop oder Dienst abfließen, und das hängt davon ab, wie schnell dessen Entwickler updaten.