picklescan est un outil open-source largement utilisé pour analyser des modèles de machine learning et d’autres archives de fichiers à la recherche de données pickle Python malveillantes. Les fichiers pickle représentent un format de sérialisation courant en Python, mais ils sont notoirement non sécurisés, car la désérialisation d’un objet pickle spécialement conçu peut conduire à l’exécution de code arbitraire. Cette bibliothèque est souvent intégrée dans des pipelines de sécurité, des dépôts d’artefacts et des systèmes de téléchargement de fichiers pour prévenir les attaques contre les applications qui traitent des modèles IA/ML ou d’autres structures de données Python.

L’impact de cette vulnérabilité est critique. Elle permet de contourner complètement la fonction de sécurité du scanner. Un attaquant non authentifié peut créer une archive ZIP malveillante que picklescan ne parviendra pas à analyser correctement, la déclarant à tort comme sûre. Lorsqu’une application en aval se fie à ce résultat et traite le fichier pickle malveillant contenu à l’intérieur, une exécution de code à distance non authentifiée peut se produire.

Il existe un exploit public disponible pour cette vulnérabilité, et il est largement discuté dans les milieux de la sécurité. Bien qu’il ne soit pas encore répertorié dans le catalogue KEV de la CISA, la disponibilité de l’exploit augmente considérablement la probabilité d’une exploitation active. Toute application exposée à Internet qui utilise cette bibliothèque pour analyser des archives ZIP non fiables est immédiatement exposée à un risque de compromission.

Produit	picklescan
Date	05/12/2025 00:16:11

Résumé technique

La cause principale de la vulnérabilité est classée comme CWE-755 : Gestion inappropriée des conditions exceptionnelles. Le composant d’analyse ZIP de l’outil picklescan ne gère pas correctement les exceptions qui surviennent lors du traitement de fichiers malformés au sein d’une archive ZIP.

La chaîne d’attaque se déroule comme suit :

1. L’attaquant crée une archive ZIP contenant au moins deux fichiers. Le premier fichier est intentionnellement corrompu avec un Cyclic Redundancy Check (CRC) erroné. Le second fichier est un objet pickle légitime mais malveillant.
2. Lorsque picklescan ouvre l’archive et tente de lire le premier fichier, le CRC corrompu génère une exception zlib.error.
3. La fonction d’analyse ne gère pas cette exception spécifique au sein de la boucle d’itération des fichiers. L’exception non gérée se propage et provoque l’interruption prématurée de l’ensemble du processus d’analyse.
4. Comme le processus se bloque, le scanner n’analyse jamais le second fichier contenant la charge utile (payload) pickle malveillante. Aucune erreur n’est signalée à l’application appelante indiquant une analyse partielle ou échouée.
5. L’application en aval, supposant que l’analyse a été effectuée avec succès et n’a détecté aucune menace, procède à l’extraction et à la désérialisation du fichier pickle malveillant, activant ainsi la charge utile d’exécution de code à distance.

Différence conceptuelle du code :

# Logique vulnérable
def scan_zip_archive(archive):
    # Une exception ici met fin à toute la fonction
    for member in archive.infolist():
        file_content = archive.read(member.filename)
        scan_for_malicious_pickles(file_content)

# Logique corrigée
def scan_zip_archive(archive):
    for member in archive.infolist():
        try:
            # L'exception est gérée par fichier, permettant à la boucle de continuer
            file_content = archive.read(member.filename)
            scan_for_malicious_pickles(file_content)
        except zlib.error:
            log("Impossible de lire le membre en raison d'une erreur CRC :", member.filename)
            continue

Un attaquant peut exploiter ce contournement pour exécuter du code arbitraire avec les permissions de l’application qui traite le fichier, conduisant à une compromission complète du système. Les versions spécifiquement affectées n’ont pas été divulguées ; il est conseillé aux utilisateurs de supposer que toutes les versions antérieures au dernier correctif sont vulnérables.

Recommandations

• Appliquer le correctif immédiatement : Mettre à jour la bibliothèque picklescan vers la version la plus récente disponible. Les développeurs doivent s’assurer que les systèmes de gestion des dépendances sont configurés pour récupérer la version corrigée.
• Atténuations : S’il n’est pas possible d’appliquer le correctif immédiatement, encapsulez les appels à la bibliothèque picklescan dans un bloc robuste de gestion des exceptions. Surveillez toute exception provenant de la bibliothèque lors du traitement des fichiers ZIP et considérez ces événements comme des échecs d’analyse, en rejetant l’archive. Évaluez la possibilité de désactiver temporairement le traitement de tous les fichiers ZIP provenant de sources non fiables.
• Chasse et surveillance :
  • Analysez les journaux système et applicatifs à la recherche d’exceptions non gérées concernant zlib.error ou le traitement de fichiers ZIP, surtout dans les applications Python.
  • Surveillez les processus Python qui génèrent des processus enfants inattendus, tels que /bin/sh, bash, powershell.exe ou des utilitaires réseau comme curl et wget.
  • Recherchez les fichiers nouvellement créés dans des chemins inhabituels, surtout ceux écrits par le compte utilisé pour exécuter l’application qui utilise picklescan.

• Réponse aux incidents : En cas de suspicion de compromission, isolez immédiatement l’hôte affecté du réseau pour prévenir les mouvements latéraux. Conservez les journaux, les vidages mémoire et les images disque pour une analyse forensique. Enquêtez sur l’activité de l’application pour identifier le moment de la compromission et toutes les données éventuellement exfiltrées.
• Défense en profondeur : Exécutez les applications qui traitent des fichiers externes non fiables dans des environnements sandbox ou conteneurisés avec des privilèges minimaux. Mettez en œuvre la segmentation du réseau pour limiter la capacité de l’application à communiquer avec les systèmes internes, réduisant ainsi l’impact d’une violation potentielle.

[Callforaction-THREAT-Footer]