skrkcb2/cve-2024-5452Detaillierte technische Analyse von CVE-2024-5452, einer Remote-Codeausführungs-Schwachstelle in PyTorch Lightning über DeepDiff-Delta-Eigenschaftsverschmutzung, mit Proof-of-Concept und Leitfaden zur Schadensbegrenzung.
RCE (Remote Code Execution) ist eine Schwachstelle, die es einem Angreifer ermöglicht, beliebigen Code aus der Ferne in einem System oder einer Anwendung auszuführen. Sie fällt unter CWE-94: Unzureichende Kontrolle der Codegenerierung ('Code Injection').
PyTorch Lightning ist eine Bibliothek, die das Training von Deep-Learning-Modellen auf Basis von PyTorch erleichtert. DeepDiff ist eine Bibliothek, die zwei Python-Objekte vergleicht und die Unterschiede analysiert.
CVE-2024-5452 ist eine Schwachstelle, die in den Webanwendungsfunktionen von Lightning im Zusammenhang mit KI-Modellgewichten auftritt. Dabei werden DeepDiff und Lightning genutzt. Durch eine schwache Header-Validierung in DeepDiff und eine Kontamination der Delta-Attribute kommt es während der Deserialisierung zu einem RCE.
Wir werden uns den Codeablauf ansehen, durch den ein Angreifer beliebige Objekte injizieren oder einen Remote Code Execution (RCE) ausführen kann, und nach Abhilfemaßnahmen suchen.
In pytorch-lightning kann über den DeepDiff-Endpunkt /api/v1/delta der Webanwendung ein Angriff durch Kontamination der Delta-Attribute erfolgen.
Anhand eines Beispiels wollen wir untersuchen, wie eine Kontamination der Dunder-Attribute des Deltas eine Deserialisierungsschwachstelle auslöst.
Die erste Anfrage ist ein Client-Angriffsbeispiel: Kontaminationskonfiguration -> Schwache Header-Validierung in Deepdiff's /api/v1/delta -> Speichern des Zustands durch Kontaminationskonfiguration.
[Abbildung 1] POC - Endpunkt-Angriff
[Abbildung 2] POC - Schwachstelleninjektion / Gesamter Inhalt der Kontaminationskonfiguration
[Abbildung 3] lightning/api/core/api.py / Teil der schwachen Header-Überprüfungslogik
[Abbildung 4] lightning/api/core/app.py / Konfigurationsabschnitt
[Abbildung 5] lightning/api/core/app.py / Abschnitt zum Speichern der Konfiguration
Die erste Anfrage umgeht die Header-Überprüfung von /api/v1/delta in [Abbildung 3] mittels [Abbildung 1], injiziert manipulierte Kontaminationskonfiguration (Delta) [Abbildung 2] und speichert die Konfiguration über [Abbildung 4] und [Abbildung 5].
Betrachten wir nun, wie diese manipulierten Delta-Konfigurationen in der zweiten Anfrage wirken.
[Abbildung 6] lightning/api/core/app.py / Anfänglicher Pfadablauf
[Abbildung 7] isinstance-Kontaminationsfall
[Abbildung 8] isinstance-Kontaminationsfall 1
[Abbildung 9] isinstance-Kontaminationsfall 2
[Abbildung 10] isinstance-Kontaminationsfall 3
[Abbildung 11_1] /lightning/app/core/flow.py - _INTERNAL_STATE_VARS Prüffunktion
[Abbildung 11_2] /lightning/app/core/flow.py - __setattr__
Mit [Abbildung 11] ist die gesamte Kontamination und Konfiguration abgeschlossen.
[Abbildung 12] RCE-Befehl
[Abbildung 13] RCE-Antwort
Schließlich wird in [Abbildung 13] exec mit Root-Rechten aufgerufen, um den Befehl aus [Abbildung 12] auszuführen und den Angriff abzuschließen.
Bisher haben wir den Ablauf einer RCE-Schwachstelle durch Objekt-Deserialisierung (CVE-2024-5452) in der Lightning-Umgebung betrachtet. Da es sich um einen Angriff handelt, bei dem der Server selbst übernommen wird, sind Abhilfemaßnahmen wichtig. Daher empfehlen wir ein Update auf die neueste Version.
/api/v1/delta hinzu (Pfad: /lightning/app/core/api) oder verstärken Sie die Sitzungsprüfung oben.
Wir haben uns die Schwachstelle angesehen, die durch Kontamination von Dunder-Attributen über Lightning und DeepDiff einen RCE auslöst. Diese Schwachstelle trat erstens durch eine schwache Header-Validierung und zweitens durch eine schwache Prüfung der Delta-Attribute bei der Objekt-Deserialisierung auf.