Es enthält keinen Artefakt-Builder, kein Upload-Artefakt, keinen Exploit-Treiber, keinen Marshal-Konstruktor, keinen Callback-Code, keinen Diagnose-Endpunkt, kein Loader-Tracing, kein benutzerdefiniertes Boot-Skript, keine Ziel-Geheimnis-Fixtur und keine Nur-Exploit-Route. Es setzt VIPS_TRACE nicht, ordnet die Prozessumgebung nicht neu, überschreibt den Active-Storage-Serializer nicht und konfiguriert keinen nicht standardmäßigen Bildprozessor.

Das root .dockerignore sendet nur Dockerfile und overlay/ an den Build. Die hostseitigen Python-Skripte und alle erzeugten Artefakte sind vom Docker-Build-Kontext ausgeschlossen, nicht nur vom finalen Kopierschritt weggelassen.

Das vollständige Ziel-Overlay besteht aus fünf gewöhnlichen Dateien:

Die Show-Seite verwendet die minimale normale Transformation:

Eine unberührte neue Rails-Anwendung hat kein Anwendungsmodell und keine Seite, die einen Anhang akzeptiert, daher sind diese fünf Dateien die minimale Anwendungsfunktionalität, die benötigt wird, um die Bedingung des nicht vertrauenswürdigen Bild-Uploads aus dem Advisory darzustellen.

Das verwundbare Ziel bauen und ausführen

Voraussetzungen sind Docker, OpenSSL, Python 3 und h5py für den Artefakt-Builder.

In Terminal 1:

Das Skript baut minimal-rails-vips:8.1.3, erzeugt eine ephemere SECRET_KEY_BASE, sofern nicht bereits eine bereitgestellt wird, veröffentlicht die Anwendung nur unter 127.0.0.1:3000 und führt den erzeugten Entrypoint und den Standardbefehl des Images aus. Kein Quellverzeichnis oder Artefakt wird in das Ziel eingebunden.

Wenn Port 3000 bereits belegt ist, wählen Sie einen anderen Loopback-Port, ohne das Image zu ändern:

Verwenden Sie denselben Port im --target des Treibers.

Den kombinierten Builder und Treiber ausführen

In Terminal 2:

rails_vips_oast_poc.py ist ein Einmal-Builder und HTTP-Treiber. Sofern --artifact nicht angegeben ist, konstruiert es den Upload in einem privaten temporären Verzeichnis, behält ihn für die vollständige Anfragesequenz und entfernt ihn, wenn der Prozess beendet wird. Es konstruiert beide Stufen, anstatt eine statische Nutzlast zu entpacken:

1. Es bittet h5py, eine MATLAB/HDF5-Datei mit einem 512-Byte-Benutzerblock zu erstellen.
2. Es erstellt ein 1 × 1024-Little-Endian-uint8-Dataset namens environment.
3. Das Dataset verwendet HDF5-externen Speicher, der durch /proc/1/environ unterstützt wird, mit Offset null und einer begrenzten Ausdehnung von 1.024 Byte.
4. Es fügt MATLAB_class="uint8" hinzu und schreibt den MATLAB 5.0-Header, der von libvips' matload-Sniffer verwendet wird.
5. Sein minimaler Ruby-Marshal-4.8-Schreiber konstruiert den vollständigen vorzeichenlosen OOB- Variationsgraphen.
6. Es hängt einen integritätsgeprüften Trailer an, der diesen serialisierten Graphen und ein kleines Manifest mit der OAST-URL und der Korrelations-Nonce enthält.

Das eingebettete RCE-Programm ist auf /usr/bin/curl mit einem strukturierten Argument-Array festgelegt. Es führt einen GET zur konfigurierten OAST-URL aus und sendet nur das zufällige rails_ghsa_xr9x-Korrelationstoken. Es verwendet keine Shell und enthält keine wiederhergestellten Geheimnisse, Befehlsausgaben, Dateiinhalte oder eine Zielkennung im Callback.

Artefakt-Parameter sind:

• --external-path: absolute Datei auf Zielseite, Standard /proc/1/environ;
• --bytes: begrenzte externe Ausdehnung von 128 bis 4096, Standard 1024;
• --oast: in der Nutzlast eingebettete Callback-Basis-URL; und
• --nonce: optionale 16-Byte-Hexadezimal-Nonce für ein reproduzierbares Artefakt.

Die Standard-OAST-URL ist loopback-sicher. Geben Sie eine Empfänger-URL an, die vom Container aus erreichbar ist, für den End-to-End-Check.

Um den erzeugten Upload zur Inspektion oder Wiederverwendung aufzubewahren, fügen Sie einen Artefaktpfad hinzu:

Ein vorhandenes --artifact wird validiert und wiederverwendet. In diesem Fall muss --oast, wenn angegeben, mit seiner eingebetteten Callback-URL übereinstimmen. Fügen Sie --force hinzu, um es mit den aktuellen Builder-Parametern neu zu konstruieren und atomar zu ersetzen.

Für die Artefakterstellung ohne HTTP-Anfragen ist der Begleit-Builder weiterhin verfügbar:

--target ist standardmäßig http://127.0.0.1:3000 und auf wörtliches Loopback oder localhost beschränkt.

Die erwartete verwundbare Ausgabe umfasst:

Gleichen Sie oast_nonce im Terminal mit dem rails_ghsa_xr9x=<nonce>-Abfrageparameter ab, der vom OAST-Dienst empfangen wird. Der HTTP 500 von der finalen Darstellungsanfrage ist erwartet: Der Callback erfolgt, während der authentifizierte Marshal-Hash neu aufgebaut wird, bevor die Gesamttransformation anschließend fehlschlägt.

Was der Treiber tut

Der Builder-Teil erfordert h5py; die HTTP- und kryptografischen Teile verwenden nur Pythons Standardbibliothek:

1. Es konstruiert und validiert das vollständige Upload-Artefakt und den eingebetteten vorzeichenlosen Marshal-Graphen.
2. Es lädt ein sicheres PNG über das gewöhnliche Multipart-HTML-Formular der Anwendung hoch, folgt der normalen Weiterleitung und extrahiert die Darstellungs-URL aus seinem ``-Element.
3. Es verwendet den integrierten Active-Storage-Direktupload-Endpunkt von Rails, um einen nicht angehängten Blob zu erstellen, der als image/bmp deklariert ist, und lädt dann die konstruierten Bytes hoch.
4. Es kombiniert die gültige signierte ID dieses Blobs mit dem normalen Variationsschlüssel aus dem sicheren Bild und fordert die Darstellung an.
5. Stock-Debian-libvips wählt die nicht gefuzzede matload-Operation. Das zurückgegebene PNG legt die externen Dataset-Bytes offen, einschließlich der Laufzeit- SECRET_KEY_BASE.
6. Der Treiber leitet den gewöhnlichen ActiveStorage-Verifier-Schlüssel ab, liest die bereits konstruierte Marshal-Nutzlast aus dem Artefakt, signiert sie für den variation-Zweck und fordert die resultierende Darstellungs-URL an.
7. Die Deserialisierung ruft die eingebettete /usr/bin/curl-Nutzlast auf und erzeugt den blinden OOB-Callback.

Das Ziel trägt keinen Hilfs-Endpunkt oder Signierungs-Gadget bei. Die Ruby-Klassen, die vom serialisierten Graphen verwendet werden, stammen aus Abhängigkeiten, die bereits von einem Stock-rails new-Gemfile aufgelöst wurden; die Anwendung erfordert oder konfiguriert sie nicht. Die Bildverarbeitung bleibt während des gesamten Prozesses auf dem Rails-Standardprozessor :vips.

Gepatchte Differenz

Stoppen Sie Terminal 1 mit Strg-C und führen Sie dann aus:

Führen Sie denselben kombinierten Treiberbefehl erneut aus. Wenn ein Artefakt aufbewahrt wurde, kann es durch Übergabe desselben --artifact-Pfads wiederverwendet werden. Das gepatchte Ergebnis sollte bei Folgendem stoppen:

Es werden keine Umgebungs-Pixel zurückgegeben, die eingebettete Nutzlast wird nie signiert oder übermittelt, und es erfolgt kein OAST-Callback. Active Storage 8.1.3.1 aktiviert libvips' Block für nicht vertrauenswürdige Operationen, daher wird matload abgelehnt.

Überprüfen, dass das Ziel-Image sauber ist

Die finale Laufzeitkonfiguration sollte die erzeugte sein:

Erwartet:

Überprüfen Sie das einzige Skript und bestätigen Sie, dass die PoC-Dateien fehlen:

Der einzige Skripteintrag ist das vom Generator erstellte /rails/script/.keep. Build-Tools und optionale Image-CLIs bleiben ebenfalls außerhalb der Laufzeit:

libvips ist als gemeinsame Laufzeitbibliothek vorhanden, obwohl seine CLI-Tools nicht installiert sind. Debian's Stock-Abhängigkeitsgraph liefert die verknüpfte MAT/HDF5- Formatunterstützung.

Dateien

• Dockerfile erzeugt und verpackt das minimale Stock-Ziel.
• .dockerignore verhindert, dass angreiferseitige Dateien in den Build- Kontext gelangen.
• overlay/ enthält nur die fünf normalen Rails-Anwendungsdateien.
• run_lab.sh baut und startet das Ziel, ohne den PoC auszuführen.
• rails_vips_oast_poc.py konstruiert das HDF5-Datei-Lese-Bild und die konfigurierbare OOB-Nutzlast, treibt den normalen HTTP-Fluss, stellt das Verifier-Geheimnis wieder her, signiert die eingebettete Nutzlast und löst sie aus.