Désérialisation de données non fiables : pickle et sérialisation Java

Ce que c'est

Un flux pickle est un petit programme destiné à une machine à pile ; ses codes opération peuvent importer n'importe quel module et appeler n'importe quel élément appelable avec des arguments, c'est ainsi que pickle.loads reconstruit les objets. La documentation Python (citée) avertit que le module n'est pas sûr, que des données pickle malveillantes peuvent exécuter du code arbitraire pendant la désérialisation, et que des données provenant d'une source non fiable ne doivent jamais être désérialisées. Sa section « Restricting Globals » présente l'atténuation pour les cas restants : sous-classer Unpickler, redéfinir find_class et n'autoriser qu'une liste explicite de paires module/nom. Le ObjectInputStream de Java présente la même structure : le flux nomme des classes, le runtime les instancie et exécute leur logique readObject, readResolve et readExternal, et des chaînes de classes de bibliothèques ordinaires (« gadget chains ») transforment cela en exécution de commandes. La documentation d'Oracle (citée) décrit le filtrage de sérialisation comme mécanisme de protection contre cela : un motif jdk.serialFilter, défini pour une seule application comme propriété système ou pour toute la JVM comme propriété de sécurité, qui autorise ou rejette des noms de classes et borne la taille des tableaux, la profondeur du graphe, les références et les octets du flux ; les filtres personnalisés implémentent l'API ObjectInputFilter.

Pourquoi c'est important

Ces formats sont pratiques pour les caches, les files d'attente de tâches, les magasins de sessions et le RPC, si bien qu'ils finissent par lire des données ayant traversé une frontière de confiance : un cookie, une file d'attente dans laquelle un autre locataire peut écrire, un fichier téléversé. L'attaquant n'a besoin d'aucune faille dans le code : seuls comptent le désérialiseur et les classes présentes sur le classpath ou le chemin d'import.

Comment l'appliquer

• Privilégier des formats de données pures (JSON, Protocol Buffers, MessagePack) avec validation de schéma pour tout ce qui traverse une frontière ; réserver pickle et la sérialisation Java aux données produites et consommées par le même processus de confiance.
• Si un pickle doit être accepté, le signer avec HMAC sous une clé côté serveur et vérifier la signature avant le chargement, comme le suggère la documentation de pickle, tout en continuant à restreindre les globals.
• En Java, définir jdk.serialFilter avec une liste d'autorisation et des limites de ressources (maxdepth, maxarray, maxrefs, maxbytes), ou redéfinir resolveClass comme le montre l'aide-mémoire OWASP (cité), et doter les classes métier devant être Serializable d'un readObject qui lève une exception.
• Rechercher pickle.load, ObjectInputStream, readObject, XMLDecoder et XStream.fromXML par grep lors de la relecture de code ; l'aide-mémoire liste les points d'entrée Java.
• Sur le réseau, les flux Java commencent par les octets AC ED 00 05 (rO0 en Base64) ; les repérer dans le trafic ou le stockage constitue un audit rapide.

Pièges

Une liste d'exclusion des classes de gadgets connues : de nouvelles chaînes apparaissent régulièrement. Supposer que l'indicateur « safe mode » d'un framework est activé en production. Charger des fichiers de modèles de machine learning provenant d'Internet sans vérifier si le format est un flux pickle.