Quando una decompression bomb incontra ZFS: oltre 3.700 TB scritti su un disco da 15 TB

Nel lavoro quotidiano, capita spesso di affrontare problemi di performance, sicurezza, scalabilità. Ma ogni tanto ci imbattiamo anche in casi decisamente curiosi. Oggi vogliamo condividere con voi una di queste situazioni particolari, che abbiamo incontrato su uno dei sistemi gestiti per conto di un nostro cliente.

Tutto è iniziato in modo apparentemente innocuo: un backup che dura troppo a lungo. Nulla di anomalo in apparenza, se non fosse che si trattava di un backup incrementale, operazione che in genere impiega pochi minuti. In questo caso invece il job risultava in esecuzione da ore, da tutta la notte. Comportamento sospetto.

Abbiamo quindi iniziato l’analisi del sistema, scoprendo una directory popolata da centinaia di file da 86 terabyte ciascuno. Tutti creati nella stessa giornata, e tutti contenuti in un filesystem ospitato su un disco da 15 terabyte.

Vi sembrerà assurdo. Anche noi inizialmente abbiamo pensato a un errore di visualizzazione, a qualche glitch nei comandi di sistema. Eppure era tutto reale: quei file esistevano, erano accessibili, leggibili e venivano processati dal sistema. Ma come era possibile?

Un marketplace di modelli 3D e un upload compromesso

Il sistema in questione ospita un portale marketplace dove gli utenti possono caricare e vendere modelli 3D in vari formati. I file vengono caricati, analizzati, e poi indicizzati e messi in vendita.

Qualcuno, evidentemente con un intento malevolo (o semplicemente per testare i limiti del sistema), ha pensato di caricare un file .rar spacciandolo per un modello 3D. Il file, una volta scompattato, generava un archivio enorme, teoricamente da 86 terabyte, composto interamente da zeri.

Questo tipo di file viene definito decompression bomb o anche ZIP BOMB: un file compresso molto piccolo (a volte pochi MB), che durante l’estrazione si espande enormemente, saturando risorse come disco, RAM, CPU. In scenari non protetti, può mandare fuori uso interi server.

Come fa un archivio piccolo a generare 86 TB?

Alla base di Decompression Bomb e di ZIP Bomb, la risposta è nella natura dei dati e negli algoritmi di compressione. I file contenenti solo zeri, o pattern ripetuti, sono estremamente compressibili. Gli algoritmi come Huffman coding (e derivati) lavorano assegnando codici più corti ai pattern più frequenti. Se un file è composto al 100% da un solo valore (ad esempio lo 0), la compressione può essere estremamente efficace.

Per capire meglio questo fenomeno, immaginate di dover descrivere a parole una lunga fila di 1.000.000 di zeri. Invece di scrivere ogni singolo zero, basterebbe dire “scrivi zero per un milione di volte”. È questo il principio su cui si basano gli algoritmi di compressione: codificare le sequenze ripetitive con un’informazione compatta.

Nel caso specifico, il file .rar caricato conteneva un singolo file che, nella sua versione decompressa, doveva occupare 86 TB, ma i suoi contenuti erano composti solo da byte a zero. Quando viene applicata la compressione, il risultato è un file minuscolo, persino inferiore a 10 MB, perché tutte le sequenze vengono codificate in modo estremamente compatto.

Questo tipo di contenuti non è solo altamente compressibile, ma rappresenta anche un pericolo concreto: è estremamente semplice generare file apparentemente innocui che possono esplodere in enormi consumi di spazio una volta estratti. L’effetto è tanto più devastante quanto più il sistema che li estrae è privo di controlli, quote, o protezioni su CPU, RAM o spazio su disco.

Un altro aspetto interessante è che, poiché l’algoritmo di compressione non può prevedere il contenuto del file in fase di decompressione, esso deve semplicemente seguire le istruzioni: “scrivi zero per 86.000.000.000.000 byte”. Nessun controllo viene applicato automaticamente, a meno che non sia esplicitamente previsto dal sistema o dall’applicazione. Da qui il potenziale rischio: un file di pochi MB può diventare una bomba da centinaia di terabyte.

In un contesto non preparato, questo porta facilmente alla saturazione dello storage, al crash dei servizi attivi e, nei casi peggiori, alla corruzione di dati e perdita di operatività.

Ma nel nostro caso, niente di tutto ciò è avvenuto. Perché?

L’arma segreta: OpenZFS e la compressione LZ4

Il sistema oggetto dell’attacco utilizza OpenZFS, un file system avanzato che supporta nativamente funzionalità come:

• snapshot e rollback

• verifica dell’integrità dei dati

• deduplicazione

• e, soprattutto in questo caso, compressione trasparente

OpenZFS non è soltanto un file system, ma un vero e proprio strumento di gestione avanzata dello storage. Tra le sue caratteristiche più potenti c’è la possibilità di abilitare la compressione a livello di dataset, in modo del tutto trasparente per l’applicazione e per l’utente finale. Questo significa che i dati vengono compressi al momento della scrittura e decompressi al momento della lettura, senza interventi manuali o modifiche software lato applicativo.

Cos’è LZ4?

LZ4 è un algoritmo di compressione lossless (senza perdita di dati) progettato per essere estremamente veloce, con un buon compromesso tra rapporto di compressione e velocità. Rispetto ad altri algoritmi come gzip, LZ4 offre:

• velocità di compressione e decompressione molto superiori
• consumo CPU estremamente contenuto
• supporto per dati binari e strutturati

È particolarmente efficace su dati ridondanti o ripetitivi, come nel caso dei nostri file composti da zeri. In queste condizioni, LZ4 riesce a comprimere file teoricamente enormi (decine di terabyte) in pochissimi kilobyte.

ZFS decide dinamicamente se e quanto comprimere, in base al guadagno ottenibile. Se un blocco di dati non risulta vantaggioso da comprimere, viene salvato in chiaro, evitando overhead inutile.

Nel caso specifico di questa decompression bomb, il file system ha interpretato i file decompressi (composti da zeri) e li ha immediatamente ricompattati con LZ4, arrivando a scriverli fisicamente su disco occupando solo una frazione infinitesimale dello spazio logico.

Perché non ce ne siamo accorti subito

Grazie alla compressione attiva, lo storage non ha saturato lo spazio disponibile. Il file system mostrava correttamente lo spazio libero, i servizi erano funzionanti, il carico sulla CPU era minimo. Tutto sembrava nella norma.

È proprio questo il punto di forza – e al tempo stesso il “tranello” – della compressione trasparente di ZFS: se da un lato ci protegge da scenari disastrosi come le decompression bomb, dall’altro rende difficile accorgersi immediatamente della loro presenza, perché tutto continua a funzionare in apparenza senza anomalie visibili.

Solo l’analisi di uno scheduling anomalo nei backup ci ha fatto scoprire la presenza dei file. Infatti, uno dei job era rimasto in esecuzione per molte ore, pur essendo un backup incrementale. È stato questo dettaglio a insospettirci e a far partire l’indagine.

Utilizzando i classici comandi di diagnostica abbiamo subito notato un comportamento inconsueto: ls -lh mostrava file enormi da decine di terabyte, mentre du -sh riportava consumi irrisori, inferiori a qualche megabyte. Un chiaro segnale che i file esistevano a livello logico, ma erano praticamente nulli a livello fisico grazie all’intervento del file system.

In altre parole, senza un’analisi mirata a livello di ZFS (o l’osservazione indiretta di processi anomali come i backup rallentati), non ci sarebbe stato alcun alert né allarme evidente. Questo tipo di attacco, se non gestito da un file system evoluto, avrebbe saturato lo storage in pochi secondi. Con ZFS, invece, ci siamo trovati di fronte a un’anomalia silenziosa, che abbiamo potuto studiare con calma, senza correre ai ripari in emergenza.

Compressione in ZFS: vantaggi pratici

Se non avete ancora preso in considerazione la compressione nei vostri sistemi ZFS, ecco qualche motivo concreto per farlo. Spesso si pensa alla compressione solo in ottica di risparmio di spazio, ma in realtà i benefici sono molto più ampi e strategici:

• Riduzione dello spazio occupato: la compressione permette di conservare una quantità significativamente maggiore di dati nello stesso spazio fisico. Questo è particolarmente utile in ambienti dove lo storage ha costi elevati, come nel caso di SSD NVMe o dischi enterprise-grade.

• Miglioramento delle performance: riducendo la quantità di dati scritti e letti fisicamente su disco, si riducono i tempi di accesso e il carico sulle I/O operations. In molti scenari, leggere meno dati compressi e decomprimerli in RAM è più veloce che leggere dati non compressi direttamente da disco.

• Effetto positivo su backup e snapshot: i backup compressi occupano meno spazio e sono più veloci da trasferire, soprattutto se combinati con meccanismi di deduplicazione o snapshot ZFS. Inoltre, snapshot compressi possono essere replicati tra host in modo più efficiente.

• Funzionalità trasparente: la compressione in ZFS è completamente trasparente per i software in uso. Non richiede modifiche alle applicazioni, non influisce sulla compatibilità dei file e non altera il comportamento dei processi di lettura e scrittura.

• Mitigazione di attacchi come questo: come abbiamo visto nel caso della decompression bomb, la compressione ZFS ha neutralizzato un potenziale disastro evitando la saturazione dello storage. Questo tipo di resilienza, abilitato semplicemente con un’opzione attiva, rappresenta un vantaggio di sicurezza tangibile.

Attivare la compressione LZ4 su un dataset in ZFS è semplice:

zfs set compression=lz4 tank/dataset

È possibile anche verificarne l’efficacia:

Un valore superiore a 1.0 indica che la compressione ha avuto effetto.

Cosa abbiamo fatto dopo la scoperta

Una volta compresa l’origine del problema, abbiamo bloccato l’upload di file compressi potenzialmente pericolosi, attivando:

• controlli più restrittivi sul tipo e sulla struttura dei file caricati

• un limite massimo alla dimensione espandibile degli archivi

In aggiunta, abbiamo suggerito al team di sviluppo dell’applicazione alcune buone pratiche da implementare lato software per aumentare la resilienza contro attacchi simili. Tra queste:

• eseguire un’analisi preventiva della struttura interna degli archivi compressi, anche in modalità sandbox

• calcolare, ove possibile, una stima della dimensione finale dei file una volta estratti, per identificare casi anomali prima che impattino lo storage

• applicare timeout e limiti di memoria alle operazioni di decompressione, così da bloccare eventuali abusi anche in fase di estrazione

Abbiamo poi eliminato i file creati, verificato che non ci fossero riferimenti o link pubblici a quei contenuti, e riportato il sistema in condizioni operative normali.

Lezione appresa: i file system fanno (tanta) differenza

Questa esperienza ci ha ricordato ancora una volta quanto la scelta del file system sia strategica nella gestione di un’infrastruttura. Troppo spesso si tende a sottovalutare questo aspetto, ritenendo che “uno valga l’altro”, o che il file system predefinito della distribuzione Linux sia sufficiente per ogni scenario.

Se il sistema fosse stato basato su ext4 o XFS, l’attacco avrebbe probabilmente avuto successo, saturando lo storage in pochi istanti e bloccando i servizi fondamentali. In assenza di compressione trasparente, i file da 86 terabyte ciascuno avrebbero rapidamente consumato tutto lo spazio disponibile, causando malfunzionamenti a catena, downtime e potenzialmente la perdita di dati.

Con ZFS invece, grazie alla sua architettura moderna, abbiamo contenuto l’impatto, identificato il problema con calma, e risolto senza downtime. Il file system ha agito in maniera intelligente e preventiva, comprimendo automaticamente i contenuti altamente ridondanti e impedendo la saturazione dello storage.

Questa vicenda dimostra come investire in tecnologie affidabili come OpenZFS non significhi soltanto migliorare le performance, ma anche dotarsi di una protezione strutturale contro comportamenti anomali o attacchi non convenzionali. Un file system non è solo un dettaglio tecnico: può fare la differenza tra un incidente bloccante e un semplice log di un evento curioso.

OpenZFS: una panoramica

Per chi non lo conoscesse, OpenZFS è l’implementazione open source del file system ZFS, originariamente sviluppato da Sun Microsystems nei primi anni 2000 per Solaris. Dopo l’acquisizione da parte di Oracle, la community ha portato avanti un fork indipendente, oggi attivamente mantenuto e in continua evoluzione.

OpenZFS è uno dei file system più avanzati oggi disponibili per ambienti Linux, BSD e derivati. È molto più di un file system tradizionale: si tratta di una piattaforma completa per la gestione dello storage, progettata con un focus sulla sicurezza, integrità dei dati e resilienza.

Tra le sue funzionalità chiave troviamo:

• Architettura copy-on-write (COW): ogni modifica ai dati genera una nuova copia, rendendo possibile la creazione di snapshot istantanei e rollback senza perdita.

• Integrità dei dati tramite checksum: ogni blocco scritto è accompagnato da un checksum. Se un dato si corrompe, ZFS può rilevarlo e – se configurato correttamente – correggerlo usando la ridondanza.

• Snapshot e replica efficienti: è possibile scattare snapshot leggibili istantaneamente e replicarli in modo incrementale verso sistemi remoti.

• Gestione avanzata dello storage: RAID-Z, vdev, pool, dataset, limiti di spazio, deduplicazione, compressione e caching multilivello sono solo alcune delle opzioni disponibili.

ZFS non è “pronto all’uso” su tutte le distribuzioni, ma con una minima curva di apprendimento offre robustezza e flessibilità superiori a qualsiasi file system tradizionale. In contesti mission-critical o ad alta densità di dati, la differenza si sente davvero.

Conclusione

Grazie alla compressione LZ4 di ZFS, siamo riusciti a scrivere oltre 3.700 terabyte su un disco da 15 TB senza accorgercene. Un paradosso possibile solo grazie alle caratteristiche avanzate di questo file system.

Non si è trattato di un bug, ma di un attacco creativo e malevolo, che avrebbe potuto compromettere un server intero. La combinazione tra monitoraggio costante, strumenti diagnostici e un file system moderno ci ha permesso di isolare, capire e risolvere il problema in tempi rapidi.

Ma soprattutto, questo episodio ha rafforzato la nostra convinzione che l’infrastruttura debba essere progettata non solo per le condizioni ottimali, ma anche – e soprattutto – per gestire l’imprevisto. In questo caso non è servito alcun intervento manuale d’urgenza, nessun failover, nessun ripristino. È bastato che il file system facesse il suo lavoro.

ZFS si è dimostrato all’altezza della sfida, proteggendo il sistema in modo silenzioso ma efficace. La sua capacità di reagire a situazioni anomale senza compromettere i dati o le prestazioni ne fa uno strumento imprescindibile per chi cerca affidabilità e resilienza.

La morale? Se ancora pensate che ext4 o XFS siano “più che sufficienti”, vi invitiamo a dare un’occhiata più da vicino a ZFS. Potreste scoprire che il vostro prossimo alleato per prestazioni, integrità e sicurezza è già pronto all’uso.

Buon lavoro e… attenzione alle bombe di decompressione!