exarch: la vulnerabilità sui link simbolici che abbiamo segnalato

Estrarre un archivio sembra l'operazione più innocua del mondo: si sceglie una cartella, si apre lo ZIP, i file finiscono lì. Ma quando l'archivio arriva da fuori, caricato da un utente, scaricato da un servizio esterno, allegato a un'email, decidere dove finiscono i file è una questione di sicurezza. Un archivio costruito ad arte può provare a scrivere fuori dalla cartella scelta: nei file di configurazione, negli script che il server esegue all'avvio, nella cartella di un altro utente.

exarch è una libreria nata esattamente per impedirlo. Il suo nucleo è scritto in Rust (exarch-core) e viene distribuito anche come pacchetto Python (exarch) e Node.js (exarch-rs). Il README la presenta come un'alternativa sicura a librerie come tarfile di Python e tar-fs di Node.js, che hanno una lunga storia di vulnerabilità proprio di questo tipo. La promessa centrale è una sola: i file dell'archivio restano dentro la cartella di destinazione.

Nella versione 0.6.1, e fino alla 0.8.0 esclusa, quella promessa si poteva aggirare. È il difetto descritto nell'advisory GHSA-9r5q-fvpf-p55p, pubblicato il 2 novembre 2026 e corretto in exarch 0.8.0. L'abbiamo segnalato noi: la scoperta è di Liam Giannini (Liam-G su GitHub), hacker etico e cofondatore di Webcracy. Ringraziamo il maintainer di exarch, che ha confermato il problema e pubblicato la correzione in pochi giorni.

Webcracy e la sicurezza informatica

Webcracy non si occupa solo di siti web e applicazioni. La sicurezza informatica è una parte centrale del nostro lavoro: penetration test, revisione del codice, analisi delle configurazioni, e ricerca sulle librerie e sui programmi open source che noi e i nostri clienti usiamo ogni giorno. Liam lavora come hacker etico: cerca le falle con gli stessi metodi di un attaccante, ma con l'obiettivo opposto. Quello che trova viene segnalato in privato a chi può correggerlo, e reso pubblico solo quando la correzione è disponibile. È il processo che si chiama divulgazione responsabile, ed è quello che abbiamo seguito anche qui, come per la vulnerabilità di FreeScout segnalata a ottobre.

Cosa succedeva durante l'estrazione

Per capire il problema servono due ingredienti.

Il primo è un link simbolico, un collegamento che sul filesystem si comporta come una cartella ma in realtà punta a un'altra posizione. exarch, con la configurazione predefinita, rifiuta i link simbolici contenuti nell'archivio: è una delle protezioni classiche contro gli archivi malevoli. Ma non teneva conto di un caso diverso: un link simbolico già presente nella cartella di destinazione, prima ancora dell'estrazione. Succede più spesso di quanto si pensi: cartelle condivise, aggiornamenti estratti sopra un'installazione esistente, ambienti in cui uploads o cache puntano a un altro disco.

Il secondo ingrediente è una cache delle cartelle create. Per non ripetere gli stessi controlli a ogni file, exarch ricordava quali cartelle aveva già creato durante l'estrazione e le considerava affidabili. Il problema è che la funzione Rust usata per crearle, create_dir_all, restituisce successo anche quando il percorso esiste già ed è un link simbolico verso una cartella. exarch quindi annotava come "cartella creata da me" un link che in realtà portava altrove.

All'attaccante bastava un archivio con due voci del tutto ordinarie: una cartella redirect/ e un file redirect/pwned.txt. Se nella destinazione esisteva già redirect come link verso una cartella esterna scrivibile, la prima voce faceva entrare il link nella cache delle cartelle fidate. Al momento di validare la seconda voce, exarch saltava la risoluzione del percorso padre, perché fidato, e anche quella del percorso completo, perché nell'archivio non c'erano link simbolici. Il flag O_NOFOLLOW usato in apertura protegge solo l'ultimo componente del percorso, non le cartelle intermedie. Risultato: l'estrazione terminava con successo e il file compariva in outside/pwned.txt, fuori dalla cartella scelta, con il contenuto deciso da chi aveva preparato l'archivio.

Il problema riguardava sia i TAR sia gli ZIP, con la configurazione di sicurezza predefinita. L'estrazione dei file 7z invece non era vulnerabile, perché per scelta progettuale non usava la cache delle cartelle nella validazione dei percorsi.

Quanto è grave

L'impatto concreto dipende da dove gira l'applicazione. Nel caso peggiore si tratta di una scrittura arbitraria di file fuori dalla destinazione, limitata solo dai permessi del processo. Con l'opzione skip_duplicates = false, che consente di sovrascrivere, anche file esistenti raggiungibili attraverso il link potevano essere troncati o sostituiti. Da lì le conseguenze possono essere la modifica di configurazioni, la persistenza di un attaccante, l'interruzione di un servizio, o l'esecuzione di codice quando il file scritto viene poi letto o eseguito da un altro componente.

C'è però una condizione necessaria: il link simbolico deve già trovarsi nella destinazione, e l'attaccante deve conoscerne il nome. Per questo nella segnalazione avevamo suggerito noi stessi una gravità moderata, e così è stata classificata, nella categoria CWE-59, risoluzione impropria dei link prima dell'accesso ai file. Al momento della scrittura non risulta ancora un CVE assegnato. La gravità moderata non deve però trarre in inganno: il difetto colpisce l'unica garanzia per cui una libreria come exarch viene scelta.

Come l'abbiamo verificato

Il problema è emerso dalla lettura del codice sorgente di exarch 0.6.1, seguendo il percorso di una voce dell'archivio dalla cache delle cartelle (DirCache) fino alla validazione in SafePath e all'apertura finale del file. Per confermarlo, Liam ha scritto due test di regressione, uno per TAR e uno per ZIP, che costruiscono l'archivio in memoria ed estraggono in cartelle temporanee create apposta, su Linux con Rust 1.98.0. Sulla versione vulnerabile entrambi i test fallivano perché l'estrazione riusciva e il file usciva dalla destinazione.

Insieme alla segnalazione abbiamo preparato anche una correzione minima: smettere di usare l'appartenenza alla cache come prova di sicurezza nella validazione di TAR e ZIP, allineandoli a quanto già faceva il codice 7z. Con quella modifica i due test di regressione passavano, così come gli 801 test unitari e i 136 test di integrazione esistenti. Nessun sistema di terzi è stato toccato: per dimostrare una scrittura fuori dalla destinazione basta una cartella temporanea sul proprio computer.

La correzione nella 0.8.0

Il maintainer è andato oltre la patch minima. Nella pull request #816, inclusa nella versione 0.8.0, la cache è stata eliminata e sostituita da un controllo che esamina con lstat ogni componente del percorso sotto la destinazione, per ogni file scritto. Il percorso padre viene risolto ogni volta, tranne quando coincide con la radice della destinazione. La correzione vale per TAR, ZIP e 7z, incluse le modalità di estrazione atomica.

C'è un cambiamento di comportamento da conoscere: per impostazione predefinita l'estrazione ora fallisce se nella destinazione c'è un qualsiasi link simbolico, anche uno che punta all'interno della destinazione stessa. Chi ne ha bisogno può riabilitarli con l'opzione per i link simbolici, e in quel caso vengono accettati solo se restano dentro la cartella di destinazione. Un link simbolico usato come cartella di destinazione stessa resta permesso.

La pull request dichiarava apertamente un limite residuo: un controllo basato sui percorsi lascia una finestra temporale tra la verifica e la scrittura, sfruttabile da chi ha già accesso in scrittura alla destinazione durante l'estrazione. La versione 0.9.0, uscita il 5 novembre, include tra le altre modifiche l'ancoraggio delle scritture a descrittori di directory, che è la soluzione indicata per quel caso. È un ottimo esempio di come una segnalazione possa diventare l'occasione per rafforzare un intero sottosistema, non solo per chiudere un singolo buco.

Cosa fare se usate exarch

Se usate exarch-core, il pacchetto Python exarch o il pacchetto npm exarch-rs in una versione precedente alla 0.8.0, aggiornate. Considerato che la 0.9.0 aggiunge ulteriori protezioni sulla scrittura dei file, conviene puntare direttamente all'ultima versione disponibile, verificando le modifiche incompatibili all'API indicate nelle note di rilascio. Dopo l'aggiornamento controllate anche che le vostre estrazioni non falliscano per via di link simbolici legittimi nella destinazione: è il nuovo comportamento predefinito, e la scelta più sicura è estrarre in una cartella vuota e dedicata.

Il consiglio, del resto, vale per qualsiasi libreria di estrazione, non solo per exarch: estraete gli archivi che arrivano dall'esterno in una cartella nuova, vuota, creata dal vostro processo, con un utente che ha solo i permessi indispensabili. Così anche un difetto come questo non trova link già pronti da sfruttare.

Perché facciamo ricerca su software open source

Gran parte del software che gira nelle aziende, anche in quelle che pensano di non usarne, è fatta di librerie open source come exarch, mantenute spesso da una sola persona o da piccoli gruppi. Il codice è pubblico, ma qualcuno deve leggerlo con gli occhi di chi lo vuole rompere. Dedicare tempo alla revisione di questi progetti e segnalare in modo responsabile quello che troviamo è il nostro modo di contribuire, e anche di sapere con precisione cosa stiamo mettendo in produzione per i nostri clienti.

Se la vostra applicazione accetta file caricati dagli utenti, elabora archivi, documenti o immagini provenienti dall'esterno, o semplicemente non è mai stata guardata da qualcuno che cerca le falle, ne parliamo volentieri. Il nostro lavoro di penetration testing parte proprio da qui: leggere il codice e la configurazione, capire dove un dato non viene controllato, e dirvi con precisione cosa abbiamo verificato e cosa no.

Parliamo della sicurezza delle vostre applicazioni↗