Produit	picklescan
Date	2025-12-04 12:36:15

picklescan est un outil de sécurité open-source conçu pour analyser les fichiers pickle Python à la recherche de contenus malveillants connus avant qu’ils ne soient désérialisés. Les fichiers pickle sont un format courant pour la sérialisation et le stockage d’objets Python, largement utilisés dans les flux de travail de Machine Learning (ML) et MLOps pour enregistrer et transférer des modèles entraînés, tels que ceux de la bibliothèque PyTorch. En raison des dangers intrinsèques du format pickle, qui peut exécuter du code arbitraire lors du chargement, des outils comme picklescan sont souvent mis en œuvre comme contrôle de sécurité critique.

Cette vulnérabilité annule complètement la fonction protectrice de l’outil, créant un faux sentiment de sécurité dangereux. Toute organisation utilisant picklescan pour assainir des fichiers non fiables est exposée à un risque élevé. Une exploitation réussie permet à un attaquant d’obtenir l’exécution de code arbitraire sur le système traitant le fichier, conduisant potentiellement à la compromission de données sensibles, au vol de propriété intellectuelle (comme des modèles ML propriétaires) ou à des mouvements latéraux dans le réseau. Bien qu’il n’y ait aucune preuve d’exploitation active connue, il existe une preuve de concept (PoC) publique, et l’attaque est triviale à exécuter pour un adversaire expérimenté.

Résumé technique

La vulnérabilité est une CWE-693 : Échec du mécanisme de protection et trouve son origine dans le contrôle incomplet de l’analyseur sur les modules et les variables globales dangereux au sein d’un fichier pickle. Le cœur de la faille réside dans la méthode utilisée pour identifier les modules malveillants ; l’analyseur effectue une comparaison exacte de chaînes de caractères avec une liste d’exclusion (denylist) de modules de premier niveau connus comme dangereux (ex. os, sys, asyncio).

L’analyseur ne vérifie pas de manière récursive la présence de sous-modules potentiellement dangereux. Un attaquant peut créer un fichier pickle qui appelle une fonction provenant d’un sous-module d’un module exclu, par exemple asyncio.unix_events. Comme picklescan ne vérifie que la chaîne exacte “asyncio”, l’importation de son sous-module passe inaperçue et le fichier est erronément marqué comme sûr.

La chaîne d’attaque est la suivante :

1. Un attaquant crée un fichier pickle malveillant qui exécute du code via un sous-module d’un module de haut niveau connu comme dangereux.
2. Le fichier est soumis à une application ou à un pipeline utilisant la bibliothèque vulnérable picklescan pour l’assainissement.
3. picklescan analyse le fichier mais ne détecte pas le sous-module malveillant dans sa liste d’exclusion, le signalant comme sûr.
4. L’application, se fiant au résultat, désérialise le fichier en utilisant pickle.load().
5. Lors de la désérialisation, l’interpréteur Python exécute le code intégré, compromettant le système hôte avec les privilèges de l’application en cours d’exécution.

Versions affectées : toutes les versions de picklescan jusqu’à la 0.0.30 incluse sont vulnérables. Un correctif n’est pas encore publiquement disponible.

Une représentation conceptuelle de la logique erronée :

# Logique vulnérable conceptuelle dans picklescan
# Le contrôle échoue car "asyncio.unix_events" n'est pas présent dans l'ensemble.
DANGEROUS_GLOBALS = {"os", "sys", "asyncio"}

def is_safe(module_name):
  if module_name in DANGEROUS_GLOBALS:
    return False # Ne vérifie pas la présence de sous-modules
  return True

Recommandations

• Correctif immédiat : Une version corrigée n’a pas encore été publiée. Surveillez le dépôt du projet picklescan pour les mises à jour et passez à une version ultérieure à la 0.0.30 dès qu’elle sera disponible.
• Atténuations : L’atténuation principale consiste à respecter le principe fondamental de sécurité de ne jamais désérialiser des fichiers pickle provenant de sources non fiables ou non authentifiées, quels que soient les résultats de l’analyse. Si la désérialisation de fichiers pickle externes est nécessaire pour des raisons métier, assurez-vous qu’elle s’effectue dans un environnement fortement isolé et sandboxé (ex. un conteneur minimal sans accès au réseau et avec des permissions de lecture seule sur le système de fichiers).
• Recherche & Surveillance :
  • Inventoriez toutes les applications internes, les pipelines de build et les environnements MLOps pour identifier toute utilisation de la bibliothèque picklescan.
  • Vérifiez les codes sources pour toutes les instances de pickle.load() et pickle.loads() qui traitent des fichiers provenant de sources externes. Traitez tous les fichiers précédemment considérés comme sûrs par une version vulnérable de picklescan comme potentiellement malveillants.
  • Surveillez les systèmes qui traitent des fichiers pickle pour détecter des comportements anormaux, tels que des processus enfants inattendus, des connexions réseau sortantes ou des modifications du système de fichiers local.

• Réponse aux incidents :
  • Si une compromission est suspectée, isolez immédiatement l’hôte touché du réseau pour empêcher l’extension de l’impact.
  • Conservez le fichier pickle malveillant, les journaux système et une image forensique de la machine aux fins de l’enquête.

• Défense en profondeur :
  • Exécutez tous les processus de traitement de données, en particulier ceux nécessitant une désérialisation, en tant qu’utilisateur à faible privilège pour réduire la surface d’attaque en cas d’exécution de code.
  • Mettez en œuvre un filtrage rigoureux du trafic sortant sur les serveurs pour bloquer tout canal de commande et contrôle (C2).
  • Évaluez l’utilisation de formats de sérialisation plus sécurisés comme JSON pour l’échange de données avec des sources non fiables.

[Callforaction-THREAT-Footer]