CVE-2025-10157: Unvollständige Global-Kontrolle in picklescan ermöglicht Umgehung des Sicherheitsscans und beliebige Codeausführung

Produktpicklescan
Datum2025-12-04 12:36:15

picklescan ist ein Open-Source-Sicherheitstool, das entwickelt wurde, um Python-Pickle-Dateien auf bekannte schädliche Inhalte zu scannen, bevor sie deserialisiert werden. Pickle-Dateien sind ein gängiges Format zur Serialisierung und Speicherung von Python-Objekten und werden häufig in Machine-Learning- (ML) und MLOps-Workflows verwendet, um trainierte Modelle, wie beispielsweise aus der PyTorch-Bibliothek, zu speichern und zu übertragen. Aufgrund der inhärenten Gefahren des Pickle-Formats, das beim Laden beliebigen Code ausführen kann, werden Tools wie picklescan oft als kritische Sicherheitskontrolle eingesetzt.

Diese Schwachstelle hebt die Schutzfunktion des Tools vollständig auf und erzeugt ein gefährliches falsches Sicherheitsgefühl. Jede Organisation, die picklescan zur Bereinigung nicht vertrauenswürdiger Dateien verwendet, ist einem hohen Risiko ausgesetzt. Ein erfolgreicher Exploit ermöglicht es einem Angreifer, beliebigen Code auf dem System auszuführen, das die Datei verarbeitet, was potenziell zur Kompromittierung sensibler Daten, zum Diebstahl geistigen Eigentums (wie proprietäre ML-Modelle) oder zur lateralen Bewegung im Netzwerk führen kann. Obwohl es keine Beweise für aktive Ausnutzungen gibt, existiert ein öffentlicher Proof-of-Concept, und der Angriff ist für einen erfahrenen Angreifer trivial durchzuführen.

Technische Zusammenfassung

Die Schwachstelle ist ein CWE-693: Schutzmechanismus-Versagen und liegt in der unvollständigen Überprüfung gefährlicher Module und Globals innerhalb einer Pickle-Datei durch den Scanner begründet. Der Kern des Fehlers liegt in der Methode zur Identifizierung schädlicher Module; der Scanner führt einen exakten String-Vergleich mit einer Denylist (Sperrliste) bekannter gefährlicher Top-Level-Module durch (z. B. os, sys, asyncio).

Der Scanner prüft nicht rekursiv auf das Vorhandensein potenziell gefährlicher Untermodule. Ein Angreifer kann eine Pickle-Datei erstellen, die eine Funktion aus einem Untermodul eines ausgeschlossenen Moduls aufruft, zum Beispiel asyncio.unix_events. Da picklescan nur den exakten String “asyncio” prüft, bleibt der Import seines Untermoduls unbemerkt und die Datei wird fälschlicherweise als sicher markiert.

Die Angriffskette sieht wie folgt aus:

  1. Ein Angreifer erstellt eine schädliche Pickle-Datei, die Code über ein Untermodul eines bekannten gefährlichen Top-Level-Moduls ausführt.
  2. Die Datei wird an eine Anwendung oder Pipeline übermittelt, die die anfällige Bibliothek picklescan zur Bereinigung verwendet.
  3. picklescan analysiert die Datei, erkennt das schädliche Untermodul jedoch nicht in seiner Sperrliste und meldet sie als sicher.
  4. Die Anwendung vertraut dem Ergebnis und deserialisiert die Datei mittels pickle.load().
  5. Während der Deserialisierung führt der Python-Interpreter den eingebetteten Code aus und kompromittiert das Host-System mit den Privilegien der ausgeführten Anwendung.

Betroffene Versionen: Alle Versionen von picklescan bis einschließlich 0.0.30 sind anfällig. Ein Fix ist derzeit noch nicht öffentlich verfügbar.

Eine konzeptionelle Darstellung der fehlerhaften Logik:

# Konzeptionelle anfällige Logik in picklescan
# Die Prüfung schlägt fehl, da "asyncio.unix_events" nicht im Set enthalten ist.
DANGEROUS_GLOBALS = {"os", "sys", "asyncio"}

def is_safe(module_name):
  if module_name in DANGEROUS_GLOBALS:
    return False # Prüft nicht auf das Vorhandensein von Untermodulen
  return True

Empfehlungen

  • Sofortiges Patchen: Eine korrigierte Version wurde noch nicht veröffentlicht. Überwachen Sie das picklescan-Projekt-Repository auf Updates und aktualisieren Sie auf eine Version nach 0.0.30, sobald diese verfügbar ist.
  • Abhilfemaßnahmen: Die primäre Abhilfemaßnahme besteht darin, das grundlegende Sicherheitsprinzip einzuhalten, niemals Pickle-Dateien aus nicht vertrauenswürdigen oder unauthentifizierten Quellen zu deserialisieren, unabhängig von den Scan-Ergebnissen. Wenn die Deserialisierung externer Pickle-Dateien aus geschäftlichen Gründen erforderlich ist, stellen Sie sicher, dass dies in einer stark isolierten Sandbox-Umgebung erfolgt (z. B. ein minimaler Container ohne Netzwerkzugriff und mit schreibgeschützten Dateisystemberechtigungen).
  • Suche & Überwachung:
    • Inventarisieren Sie alle internen Anwendungen, Build-Pipelines und MLOps-Umgebungen, um eine mögliche Nutzung der picklescan-Bibliothek zu identifizieren.
    • Überprüfen Sie den Quellcode auf alle Instanzen von pickle.load() und pickle.loads(), die Dateien aus externen Quellen verarbeiten. Behandeln Sie alle Dateien, die zuvor von einer anfälligen Version von picklescan als sicher eingestuft wurden, als potenziell schädlich.
    • Überwachen Sie Systeme, die Pickle-Dateien verarbeiten, auf anomales Verhalten, wie unerwartete Kindprozesse, ausgehende Netzwerkverbindungen oder Änderungen am lokalen Dateisystem.

  • Reaktion auf Vorfälle:

    • Wenn eine Kompromittierung vermutet wird, isolieren Sie den betroffenen Host sofort vom Netzwerk, um eine Ausweitung der Auswirkungen zu verhindern.
    • Bewahren Sie die schädliche Pickle-Datei, Systemprotokolle und ein forensisches Abbild der Maschine für Untersuchungszwecke auf.

  • Defense in Depth:

    • Führen Sie alle Datenverarbeitungsprozesse, insbesondere solche, die eine Deserialisierung erfordern, als Benutzer mit niedrigen Privilegien aus, um den Wirkungsbereich im Falle einer Codeausführung zu begrenzen.
    • Implementieren Sie eine strikte Filterung des ausgehenden Datenverkehrs auf Servern, um mögliche Command-and-Control-Kanäle (C2) zu blockieren.
    • Erwägen Sie die Verwendung sicherere Serialisierungsformate wie JSON für den Datenaustausch mit nicht vertrauenswürdigen Quellen.

[Callforaction-THREAT-Footer]

Leave a Reply

Your email address will not be published. Required fields are marked *