Pochi giorni fa abbiamo parlato dell’outage di Cloudflare e delle conseguenze che ci sono state su tutti i servizi globali che si appoggiano a questo colosso.

Per capire meglio come e perché è avvenuto il disservizio è bene tornare sulle dichiarazioni ufficiali nel blog post di Cloudflare da parte di Matthew Prince, il CEO della piattaforma.

Chiariamo subito che il disservizio non è causato da un attacco informatico:

The issue was not caused, directly or indirectly, by a cyber attack or malicious activity of any kind.

Il problema non è stato causato, direttamente o indirettamente, da un attacco informatico o da attività dannose di alcun tipo.

Il primo tassello del problema, come spiegato nel blog post, è il cambio di autorizzazioni in uno dei database di Cloudflare che ha iniziato a scrivere le entry su un cosiddetto “Feature File” il quale è inaspettatamente raddoppiato di dimensioni ed è stato propagato in tutte le macchine dell’infrastruttura, causando un disservizio distribuito (una specie di DDoS autoindotto).

I software che avevano come compito quello di fare il “parsing” dei file per tenere aggiornato il Bot Management system avevano come limite di dimensione del file una dimensione inferiore a quella del nuovo Feature File generato. Questo ha fatto sì che tutti i sistemi siano andati in crash (gradualmente) per la stessa causa.

Il file, come spiega il blog post, era generato ogni 5 minuti e l’unico modo per fermare il disservizio è stato generarne uno nuovo e propagarlo nella rete.

Nella pratica, però, il crash è stato causato da una funzione specifica di Rust, ovvero unwrap(), scatenata dopo che i sistemi che computavano il Feature File hanno incontrato il limite di 200 feature.

Ancora Rust quindi, con buona pace di quanti pensano che basti usare un linguaggio sicuro “by-design” per dormire sonni tranquilli.

Il pezzo di codice incriminato è il seguente:

Nello specifico la funzione che fa il fetch delle feature ha come check l’unwrap() che manda il codice in panic nel caso in cui l’operazione su cui viene fatto l’unwrap() sia None oppure Err:

thread fl2_worker_thread panicked: called Result::unwrap() on an Err value

Da questo momento in poi, tutti i proxy che si basano su questa funzione hanno restituito i codici di errore 5xx che hanno fatto segnare il downtime di Cloudflare:

In merito all’errore dell’ unwrap() la community si è subito divisa.

C’è stato chi ha dato completamente la colpa a Cloudflare dicendo che un codice del genere non può andare in produzione ma deve essere sostituito da funzioni più sicure, come unwrap_or() e unwrap_or_default() (che possono gestire l’errore riscontrato senza mandare in panic il codice), c’è chi si è schierato contro la nomenclatura delle funzioni di Rust, dicendo che il nome unwrap() fosse poco “parlante” e c’è anche chi dice che la funzione non ha la piena colpa del crash ma è stato tutto causato da una cattiva gestione degli errori e (forse) da una gestione dell’infrastruttura che ha trascurato le conseguenze che può avere un errore sul codice.

Insomma, in un modo o nell’altro per una serie di errori banali, cattive pratiche di programmazione e magari un po’ di Vibe Coding (e Linus Torvalds sul tema è stato piuttosto chiaro), una buona parte dell’Internet che usiamo tutti i giorni è andata giù per un bel po’ di ore.

C’è addirittura chi, durante questo lasso di tempo, ha abbandonato temporaneamente Cloudflare per non avere downtime e si è esposto al rischio di attacchi pur di continuare a fornire i servizi.

In conclusione, l’outage di Cloudflare dimostra quanto anche le infrastrutture più solide che riescono a sventare attacchi DDoS di 7.3 Tbps possano crollare per una serie di piccoli errori tecnici e scelte poco accorte.

Non sono stati gli attacchi da record o exploit zero-day a mandare giù un gigante della rete, ma un insieme di dettagli sottovalutati. Insomma, un promemoria chiaro: nei sistemi complessi, basta poco per trasformare un piccolo errore in un blackout globale.