Produktdefinition: Picklescan ist ein Sicherheitswerkzeug, das entwickelt wurde, um Python-Pickle-Dateien auf bösartigen Code zu untersuchen, bevor diese deserialisiert werden. Es wird häufig in Machine Learning (ML) und MLOps-Umgebungen eingesetzt, um das Risiko einer Remote Code Execution (RCE) beim Laden von Modellen oder Daten aus nicht vertrauenswürdigen Quellen zu mindern. Seine Hauptfunktion besteht darin, als Sicherheitsbarriere innerhalb der ML-Lieferkette zu fungieren.

Risikoprofil: Diese Schwachstelle ermöglicht es, die Scan-Funktionen des Tools vollständig zu umgehen, was ein hohes Risiko für eine nicht authentifizierte Remote Code Execution darstellt. Ein Angreifer kann eine bösartige Datei erstellen, die von einer anfälligen Version von Picklescan fälschlicherweise als sicher eingestuft wird. Jede nachgelagerte Anwendung, die diesem Ergebnis vertraut und die Datei lädt, wird kompromittiert. Die Schwachstelle untergräbt die grundlegende Sicherheitsgarantie des Tools.

Threat Intelligence: Ein Proof-of-Concept-Exploit ist öffentlich verfügbar. Derzeit sind jedoch keine Fälle einer aktiven Ausnutzung dieser Schwachstelle bekannt. Sie ist nicht im Katalog der bekannten ausgenutzten Schwachstellen (KEV) der CISA enthalten.

Expositionsfläche: Unternehmen sind gefährdet, wenn sie Picklescan-Versionen bis einschließlich 0.0.30 in automatisierten Workflows verwenden, wie z. B. in CI/CD-Pipelines zur Modellvalidierung oder auf öffentlichen Plattformen zur Modellaufnahme. Auch einzelne Entwickler und Data Scientists, die sich auf das Tool verlassen, um Modelle von Drittanbietern zu überprüfen, sind betroffen.

Produkt	picklescan
Datum	2025-12-04 12:14:50

Technische Zusammenfassung

Analyse der Grundursache: Die Schwachstelle ist ein Problem der CWE-20: Unsachgemäße Eingabevalidierung in der Logik der Dateianalyse. Picklescan ändert die Strenge des Scans basierend auf der Dateiendung. Wenn es auf eine Datei mit einer PyTorch-zugehörigen Endung (z. B. .pt, .pth) stößt, führt es keine tiefgehende Untersuchung auf gefährliche Pickle-Opcodes durch. Dies ermöglicht es einem standardmäßigen bösartigen Pickle-Payload, der normalerweise erkannt würde, die Analyse vollständig zu umgehen, wenn er in einer Datei mit einer dieser Endungen gekapselt ist.

Schritt-für-Schritt-Angriffskette:

1. Erstellung des Payloads: Ein Angreifer erstellt einen bösartigen Payload unter Verwendung standardmäßiger Python-Pickle-Serialisierungstechniken. Dies beinhaltet typischerweise die Verwendung der __reduce__-Methode, um eine gefährliche Funktion wie os.system oder subprocess.run aufzurufen.
2. Umgehung: Der Angreifer speichert die bösartige Pickle-Datei mit einer PyTorch-zugehörigen Endung, zum Beispiel malicious_model.pt.
3. Scan-Bypass: Die anfällige Version von Picklescan wird aufgerufen, um malicious_model.pt zu analysieren. Aufgrund der fehlerhaften Validierungslogik im Zusammenhang mit der .pt-Endung erkennt das Tool die gefährlichen Opcodes nicht und meldet die Datei als sicher.
4. Ausführung: Eine nachgelagerte Anwendung oder ein Entwickler vertraut dem Scan-Ergebnis und lädt die Datei mit einer Standardfunktion wie pickle.load(). Der Deserialisierungsprozess führt den eingebetteten Payload aus und löst die Remote Code Execution auf dem Host-System mit den Berechtigungen der Anwendung aus.

Konzeptionelle Codelogik: Das folgende Beispiel illustriert das gefährliche Muster, ist jedoch kein direkter Exploit. Die Schwachstelle liegt darin, dass Picklescan solche Strukturen in .pt-Dateien nicht erkennt.

# Konzeptionelles Beispiel eines bösartigen Pickle-Objekts
# Ein Angreifer fügt diese Struktur in eine .pt-Datei ein, um den Scanner zu umgehen.
# Dieser Code dient nur zu Illustrationszwecken.

import os

class Exploit:
    def __reduce__(self):
        # Diese Funktion wird während der Deserialisierung automatisch aufgerufen.
        # Ein Angreifer würde hier einen Befehl einfügen, der auf dem Zielsystem ausgeführt werden soll.
        cmd = ("echo 'Code execution achieved' > /tmp/pwned")
        return (os.system, (cmd,))

# Wenn ein Programm pickle.load() auf eine Datei anwendet, die dieses serialisierte Objekt enthält,
# wird os.system(cmd) ausgeführt.

Betroffene Versionen:

• Anfällig: Picklescan-Versionen bis einschließlich 0.0.30
• Behoben: Die Korrektur ist ab der Picklescan-Version 0.0.31 verfügbar

Empfehlungen

• Sofortiges Update: Aktualisieren Sie das Tool mmaitre314/picklescan auf Version 0.0.31 oder höher, um den Sicherheitspatch anzuwenden.
• Abhilfemaßnahmen:
  • Wenn der Patch nicht sofort angewendet werden kann, konfigurieren Sie die Sicherheits-Workflows so um, dass alle Dateien mit der Endung .pt oder .pth abgelehnt werden oder diese unabhängig vom Scan-Ergebnis als grundsätzlich unsicher behandelt werden.
  • Wechseln Sie zu sichereren Modell-Serialisierungsformaten, die keine Ausführungsrisiken bergen, wie z. B. safetensors.

• Suche und Überwachung:
  • Scannen Sie alle vorhandenen .pt– und .pth-Dateien in Modell-Repositories rückwirkend mit der aktualisierten Version von Picklescan, um zuvor unentdeckte bösartige Modelle zu identifizieren.
  • Überwachen Sie die Protokolle von Anwendungen, die Modelldateien deserialisieren. Achten Sie auf ungewöhnliche Kindprozesse, die vom Anwendungsprozess gestartet werden (z. B. sh, bash, curl, powershell).
  • Überprüfen Sie Netzwerkprotokolle auf verdächtige ausgehende Verbindungen von Hosts, die für das Laden und die Inferenz von Modellen zuständig sind.

• Reaktion auf Vorfälle:
  • Wenn eine Kompromittierung vermutet wird, isolieren Sie den betroffenen Host sofort vom Netzwerk, um seitliche Bewegungen (Lateral Movement) zu verhindern.
  • Bewahren Sie die verdächtige Modelldatei sowie relevante Anwendungs- und Systemprotokolle für die forensische Analyse auf.
  • Gehen Sie davon aus, dass alle Anmeldeinformationen, Schlüssel und sensiblen Daten, auf die der kompromittierte Host Zugriff hatte, exfiltriert wurden, und leiten Sie Verfahren zur Rotation und Ungültigmachung ein.

• Defense-in-Depth:
  • Führen Sie das Laden von Modellen und die Datenverarbeitung in Sandbox- oder containerisierten Umgebungen mit minimalen Berechtigungen und ohne Netzwerkzugriff aus.
  • Implementieren Sie eine strikte Netzwerksegmentierung, um sicherzustellen, dass selbst im Falle einer RCE der Aktionsradius des Angreifers begrenzt bleibt.

[Callforaction-THREAT-Footer]