Picklescan è una libreria di sicurezza progettata per analizzare i file pickle di Python alla ricerca di contenuti dannosi. I file pickle sono un metodo comune per serializzare e deserializzare strutture di oggetti Python, utilizzato estensivamente nelle pipeline di Machine Learning (ML) per salvare e caricare modelli addestrati (ad esempio modelli PyTorch). A causa del rischio intrinseco di esecuzione arbitraria di codice durante la deserializzazione, strumenti come picklescan vengono impiegati per garantire che vengano elaborati solo pickle “sicuri”.

Questa vulnerabilità rappresenta un aggiramento fondamentale della promessa centrale di sicurezza dello strumento, creando un falso senso di sicurezza. Qualsiasi applicazione Python, in particolare i sistemi ML/AI, che si affida a una versione vulnerabile di picklescan per sanificare file non attendibili è ad alto rischio. Un attaccante può creare un file dannoso che lo strumento approverà come sicuro, portando a un’esecuzione remota di codice (RCE) quando il file viene utilizzato dall’applicazione a valle.

La vulnerabilità è considerata ad alto rischio perché sovverte un controllo di sicurezza. Al momento della stesura, non sono noti exploit attivi in circolazione, e la vulnerabilità non è elencata nel catalogo KEV (Known Exploited Vulnerabilities) di CISA. Tuttavia, esiste un proof-of-concept pubblico, il che aumenta la probabilità di un futuro sfruttamento.

Riassunto tecnico

La vulnerabilità è un aggiramento della scansione di sicurezza radicato in un controllo incompleto dei moduli pericolosi all’interno di un file pickle. La causa principale è identificata come CWE-184: Elenco nero incompleto. Lo strumento picklescan esegue la validazione di sicurezza verificando se un file pickle tenta di importare e utilizzare moduli presenti in un elenco di esclusione di moduli notoriamente pericolosi (ad esempio, os, subprocess, asyncio). Tuttavia, il controllo utilizza una corrispondenza esatta della stringa del nome del modulo.

Un attaccante può eludere questo controllo facendo riferimento a un sottomodulo di un modulo bloccato. Ad esempio, se l’elenco di esclusione contiene asyncio, lo strumento lo bloccherà, ma non bloccherà asyncio.unix_events, che può comunque essere utilizzato per eseguire comandi arbitrari.

La catena d’attacco procede come segue:

1. Un attaccante crea un file pickle dannoso che importa un sottomodulo di un modulo noto e bloccato.
2. Il file viene inviato a un’applicazione Python che utilizza picklescan per la validazione.
3. picklescan analizza i moduli richiesti dal pickle e li confronta con l’elenco di esclusione.
4. Poiché il sottomodulo (ad esempio, asyncio.unix_events) non corrisponde esattamente a nessuna voce dell’elenco (ad esempio, asyncio), la scansione classifica erroneamente il file come sicuro.
5. L’applicazione, fidandosi del risultato della scansione, procede alla deserializzazione del file usando pickle.load() di Python o una funzione equivalente.
6. Il processo di deserializzazione esegue il codice specificato nel file pickle, provocando un’esecuzione arbitraria di codice con i privilegi dell’applicazione Python.

Il difetto concettuale può essere illustrato come segue:

# Logica concettualmente vulnerabile
# Un elenco di esclusione di moduli pericolosi.
DENYLIST = {"os", "subprocess", "asyncio"}

# Il controllo fallisce perché "asyncio.unix_events" non è presente nell’insieme.
def is_module_denied(module_name):
    return module_name in DENYLIST

# Logica corretta concettuale
# La correzione include il controllo del modulo base oltre al percorso completo.
def is_module_denied_fixed(module_name):
    base_module = module_name.split('.')[0]
    return base_module in DENYLIST or module_name in DENYLIST

Le versioni specifiche vulnerabili e quelle corrette di picklescan non erano disponibili al momento della redazione. Gli utenti dovrebbero aggiornare alla versione più recente disponibile.

Raccomandazioni

• Applicare la patch immediatamente: aggiornare picklescan all’ultima versione disponibile che include la correzione per l’aggiramento tramite sottomoduli.
• Mitigazioni: la difesa principale consiste nel non deserializzare mai file pickle provenienti da fonti non attendibili, indipendentemente dalla scansione di sicurezza. Quando possibile, utilizzare formati di serializzazione dati più sicuri come JSON o YAML (con caricamento sicuro). Se l’uso di pickle è inevitabile, assicurarsi che l’applicazione che elabora i dati venga eseguita con i privilegi minimi possibili e sia fortemente isolata.
• Attività di monitoraggio e individuazione:
  • Esaminare i log delle applicazioni alla ricerca di eventuali errori di deserializzazione o comportamenti anomali legati all’elaborazione dei file.
  • Monitorare i sistemi che eseguono applicazioni Python per processi figli sospetti. Un processo Python che avvia inaspettatamente shell (sh, bash, powershell) o strumenti di rete (curl, wget, nc) è un forte indicatore di compromissione.
  • Ispezionare il traffico di rete per rilevare connessioni in uscita inattese dai server applicativi che gestiscono il caricamento dei file.
• Risposta agli incidenti: se si sospetta una compromissione, isolare immediatamente l’host coinvolto dalla rete. Conservare i log applicativi, i file caricati e un’immagine di memoria del processo in esecuzione per analisi forensi. Indagare su eventuali segni di movimento laterale o esfiltrazione di dati originati dall’host compromesso.
• Difesa in profondità: implementare un filtering rigoroso per il traffico in uscita per bloccare comunicazioni C2 non autorizzate. Utilizzare soluzioni di controllo applicativo per impedire che l’interprete Python esegua codice o comandi di sistema non autorizzati. Eseguire regolarmente backup dei dati critici, inclusi i modelli ML, in una posizione sicura e offline.