Bug di archiviazione in Cloudflare Containers ha esposto i dati di inquilini precedenti

Bug di archiviazione in Cloudflare Containers ha esposto i dati di inquilini precedenti

Cloudflare ha corretto una falla nel suo servizio Containers che permetteva a un cliente pagante di leggere i dati residui sul disco di un container eliminato di un altro account; i clienti non devono fare nulla.

Cloudflare ha corretto una falla nel suo servizio Cloudflare Containers che permetteva a un cliente pagante di leggere i dati residui sul disco lasciati dai container di altri clienti sullo stesso server condiviso. L'azienda e il ricercatore che ha scoperto il problema, Oren Yomtov della società di sicurezza Accomplish, hanno divulgato il problema giovedì. Cloudflare afferma che i dati provenivano solo dallo spazio su disco che i container precedenti avevano usato e rilasciato, non da alcun carico di lavoro attivo, e che un attaccante non poteva scegliere di chi fossero i dati ricevuti. L'azienda ha distribuito la correzione in tutto il suo servizio, quindi i clienti non devono intraprendere alcuna azione.

Cloudflare Containers esegue i programmi dei clienti all'interno di container isolati su server condivisi da molti account, con Cloudflare che sceglie su quale server viene eseguito un carico di lavoro. Anche Cloudflare Sandboxes, che funziona sopra Containers ed è pubblicizzato come un luogo sicuro per eseguire codice non attendibile, incluso il codice scritto da agenti AI, è stato interessato. La falla è stata segnalata attraverso il programma bug bounty di Cloudflare il 4 settembre. La causa principale era nel modo in cui erano configurati i dischi condivisi. Ogni container riceve un disco costruito con una funzionalità di archiviazione Linux chiamata thin provisioning, che assegna spazio in blocchi fissi da 64 kilobyte. Quando un container veniva eliminato, i suoi blocchi tornavano in un pool condiviso disponibile a tutti gli account dei clienti. Quel pool era impostato per saltare la cancellazione di un blocco prima di assegnarlo al container successivo, anche se la cancellazione è normalmente l'impostazione predefinita. Di conseguenza, se un nuovo container scriveva solo una piccola quantità di dati in un blocco riutilizzato, il resto del blocco conteneva ancora i dati del container precedente.

Per dimostrare la falla, i ricercatori hanno scritto un piccolo blocco da quattro kilobyte in spazio non utilizzato e poi hanno letto l'intero blocco da 64 kilobyte a livello di disco grezzo, che mostra i dati prima che qualsiasi regola del file system li nasconda. I 60 kilobyte che non avevano scritto contenevano ancora byte di un container precedente. Nei test di produzione, hanno trovato materiale residuo in 18 tentativi su 24, ciascuno su un server scelto da Cloudflare, e su 20 macchine sottostanti su 22 in quattro continenti. Cloudflare ha affermato che i blocchi recuperati contenevano strutture di directory, pagine di database e file di database embedded strutturalmente completi, un formato di database ampiamente utilizzato incluso in molte applicazioni. Il resoconto dei ricercatori aggiungeva elenchi di directory, profili del browser Chromium, file .env (file di testo semplice che spesso contengono variabili d'ambiente e segreti) e file di credenziali, descrivendoli come file di altri clienti. I ricercatori hanno affermato che i loro script di analisi producevano solo conteggi e controlli di formato, non contenuti dei file, e che il materiale inviato a Cloudflare non conteneva nomi di terzi, identificatori, credenziali o contenuti recuperati. Hanno anche confermato che i dati recuperati sono stati mantenuti privati e cancellati in modo sicuro dopo l'invio. I ricercatori non hanno dimostrato che la falla potesse modificare i dati attivi di un altro cliente o mettere offline un carico di lavoro.

Cloudflare ha corretto la falla in due passaggi. In primo luogo, ha riattivato la cancellazione per i blocchi appena assegnati, il che ha fermato il metodo segnalato; i ricercatori hanno confermato il 14 settembre che il loro proof of concept, un piccolo programma di test che dimostrava la falla, non funzionava più. Tuttavia, quella modifica non ha ripulito i blocchi già mappati nei dischi dei container in esecuzione o nella cache di ogni server dei livelli di immagine preparati, che un nuovo container poteva ereditare e leggere. Quindi Cloudflare ha anche ritirato ogni disco dei container in esecuzione e cancellato quelle cache, svuotando e riavviando i server durante le ore di bassa attività. La pulizia è stata completata il 19 settembre, e Cloudflare ha divulgato la falla cinque giorni dopo.

Cloudflare ha affermato di aver cercato segni che qualcun altro avesse usato il metodo. L'azienda ha creato firme di rilevamento dal proof of concept dei ricercatori e dalla propria copia dell'attacco, poi le ha confrontate con i registri di attività del disco che aveva conservato. Ha trovato solo i test autorizzati dei ricercatori e dei propri ingegneri, e ha affermato di non aver visto prove che questo specifico metodo sia stato usato da qualcun altro. Questo risultato copre i registri conservati da Cloudflare, ma l'azienda non ha indicato l'intervallo di tempo di quei registri o quando è stata introdotta per la prima volta l'impostazione non sicura, quindi non è chiaro dal suo resoconto quanto sia durata l'esposizione. Separatamente, i ricercatori hanno affermato che la stessa configurazione del disco ha interessato anche il prodotto Cloudflare Browser Run, ma il post di Cloudflare nominava solo Containers e Sandboxes come interessati e non menzionava Browser Run. I ricercatori hanno descritto la falla come la loro sesta fuga da una sandbox di codice pubblicata da luglio, dopo precedenti scoperte in Anthropic's Claude Cowork e Claude Code, nello strumento da riga di comando di Cursor, in Docker e in OpenAI's Codex.

Per i proprietari di siti web e i team IT, l'incidente è un promemoria che l'infrastruttura condivisa necessita di un isolamento e di una pulizia rigorosi dell'archiviazione. Se un provider riutilizza lo spazio su disco senza cancellarlo, i vecchi file o le credenziali di un cliente possono diventare leggibili dal successivo inquilino. Per le organizzazioni che gestiscono siti web o applicazioni in ambienti condivisi, questa igiene del disco è importante; AEU Hosting offre hosting WordPress gestito protetto end to end, quindi i clienti possono chiedere direttamente a un provider come isola e cancella l'archiviazione tra gli inquilini prima di collocare dati sensibili su infrastrutture condivise.

Come Proteggerti

  1. Se usi Cloudflare Containers o Sandboxes, non devi fare nulla per questa correzione, ma controlla l'avviso di Cloudflare per confermare che il servizio sia aggiornato.
  2. Quando esegui container o server condivisi tu stesso, attiva l'impostazione che cancella lo spazio su disco liberato prima che venga riutilizzato, così i vecchi dati non possono essere letti dal prossimo inquilino.
  3. Evita di inserire file sensibili, come file che contengono password o valori di configurazione, all'interno di container usa e getta o sandbox condivise; conserva i segreti in un gestore di segreti dedicato.
  4. Chiedi al tuo provider di hosting o cloud come isola e cancella l'archiviazione tra clienti diversi prima di memorizzare dati sensibili su infrastrutture condivise.
  5. Se usi una sandbox di codice per codice generato dall'AI, trattala come non attendibile ed evita di memorizzare credenziali reali o dati privati nello stesso ambiente.

I Termini Spiegati

  • container Un luogo leggero e isolato dove viene eseguito un programma, condividendo lo stesso server con altri clienti.
  • thin provisioning Una funzionalità di archiviazione che assegna spazio su disco in piccoli blocchi solo quando necessario, invece di riservare l'intera quantità in anticipo.
  • 64-kilobyte block Un'unità di spazio su disco di dimensione fissa; in questo caso la più piccola parte che Cloudflare riutilizzava tra i container.
  • raw disk La vista di basso livello dell'archiviazione dove puoi leggere esattamente ciò che è scritto, prima che qualsiasi regola del file system lo nasconda.
  • bug bounty Un programma di ricompensa in cui un'azienda paga ricercatori esterni per segnalare vulnerabilità di sicurezza.
  • sandbox Un ambiente sicuro progettato per eseguire codice non attendibile senza permettergli di influenzare il resto del sistema.
  • image layer Una copia memorizzata nella cache dei file iniziali di un container che i nuovi container ereditano, e che può contenere dati residui se non viene pulita.
  • proof of concept Un piccolo programma di test che dimostra che una vulnerabilità di sicurezza funziona davvero.

Servizi AEU correlati