Squidbleed: falla di sicurezza rimasta nascosta in Squid Proxy per quasi 30 anni

Una vulnerabilità rimasta nascosta per quasi tre decenni dentro uno dei proxy più utilizzati su Internet riporta l’attenzione sullo scottante tema relativo alla gestione della memoria nei software scritti in C. La falla, identificata come CVE-2026-47729 e soprannominata Squidbleed, interessa il progetto Squid Proxy, componente presente da anni in ambienti aziendali, provider di servizi, infrastrutture accademiche e sistemi di caching distribuiti.

La scoperta assume un valore particolare non soltanto per il potenziale impatto, ma anche per la sua longevità. Secondo l’analisa pubblicata dai ricercatori di Calif, il difetto sarebbe presente nel codice sin dal 1997. Numerose generazioni di sviluppatori, revisioni del codice, audit di sicurezza e aggiornamenti hanno convissuto con un problema capace di esporre porzioni della memoria interna del processo utilizzato da Squid Proxy.

È una situazione che richiama inevitabilmente il caso Heartbleed (OpenSSL) del 2014, che abbiamo annoverato tra le vulnerabilità di sicurezza più devastanti della storia, anche se con presupposti tecnici differenti e una superficie di attacco più circoscritta.

Come nasce Squidbleed e come minaccia Squid Proxy

Il problema si trova nel codice che gestisce alcune operazioni legate al supporto FTP integrato in Squid. Sebbene il protocollo FTP abbia perso gran parte della sua rilevanza operativa a favore di HTTPS e SFTP, il relativo codice è rimasto attivo nelle configurazioni predefinite del software per ragioni di compatibilità storica. E proprio qui si nasconde l’errore.

Squid Proxy è un software open source nato nella seconda metà degli anni ’90 con l’obiettivo di funzionare come server proxy e sistema di caching per il traffico di rete. Il suo compito principale consiste nell’intermediare le comunicazioni tra client e server remoti, riducendo il consumo di banda e migliorando i tempi di risposta per contenuti richiesti frequentemente.

Quando un utente richiede una pagina web, la richiesta può passare attraverso Squid prima di raggiungere il server di destinazione. Se il contenuto è già presente nella cache del proxy, Squid può restituirlo immediatamente senza dover contattare nuovamente il sito remoto.

Oggi Squid è utilizzato soprattutto in ambienti aziendali, nelle Pubbliche Amministrazioni, nelle università e presso alcuni provider di servizi Internet. Le sue funzioni non si limitano al caching: può applicare politiche di accesso, filtrare siti web, autenticare utenti, registrare il traffico di rete e controllare l’utilizzo della banda disponibile.

Molte organizzazioni lo impiegano come forward proxy, cioè come intermediario per il traffico generato dagli utenti interni. In altri casi opera come reverse proxy, posizionandosi davanti a server web e applicazioni per distribuire il carico, migliorare le prestazioni e aggiungere livelli di controllo.

Quali informazioni possono fuoriuscire

La vulnerabilità in Squid Proxy deriva da una combinazione di elementi classici dello sviluppo in linguaggio C: stringhe terminate da carattere NUL, aritmetica dei puntatori e interpretazioni errate del comportamento della funzione strchr(). Una particolare condizione permette infatti di effettuare una lettura oltre i limiti previsti del buffer allocato in memoria, generando un tipico scenario di heap buffer over-read.

Come accennato in precedenza, il meccanismo scoperto da Calif ricorda da vicino le dinamiche che resero celebre Heartbleed nel 2014: l’attaccante non modifica i dati e non esegue codice arbitrario, ma induce il software a restituire informazioni che non dovrebbe mai divulgare.

Quando la condizione vulnerabile si verifica, Squid può restituire frammenti casuali della memoria del processo: il contenuto dipende da ciò che il proxy stava elaborando in quel preciso momento.

Tra i dati potenzialmente esposti figurano URL richiesti dagli utenti, intestazioni HTTP, cookie di sessione, parametri di autenticazione e altre informazioni transitate attraverso il proxy. Non esiste una garanzia sul tipo di dati ottenibili: ogni lettura può produrre risultati differenti, proprio perché il software estrae contenuti da aree di memoria non previste.

L’impatto reale dipende comunque fortemente dall’architettura in cui opera Squid. Gran parte del traffico web moderno utilizza HTTPS: in molte configurazioni il proxy si limita a inoltrare connessioni TLS attraverso il metodo CONNECT, senza decifrarne il contenuto. In tali scenari la quantità di informazioni realmente leggibili diminuisce sensibilmente. Diversa la situazione nei casi in cui il software effettua terminazione TLS, ispezione SSL o gestione di traffico HTTP in chiaro.

Le condizioni necessarie per l’attacco

Uno degli aspetti più interessanti di Squidbleed riguarda le condizioni richieste per sfruttare la vulnerabilità: non basta inviare una richiesta HTTP arbitraria al proxy.

L’attaccante deve controllare un server FTP raggiungibile dal sistema che esegue Squid e il proxy deve inoltre poter stabilire connessioni verso la porta TCP 21 del server remoto. Solo a quel punto diventa possibile costruire risposte FTP appositamente progettate per attivare il comportamento vulnerabile e provocare la lettura oltre i limiti del buffer.

La necessità di disporre di un server FTP controllato dall’attaccante riduce notevolmente la superficie di attacco rispetto a vulnerabilità più dirette. Tuttavia numerose infrastrutture mantengono ancora accesso in uscita verso servizi FTP esterni, soprattutto in ambienti legacy o industriali.

Alcune distribuzioni Linux hanno già iniziato a pubblicare bollettini nonché gli aggiornamenti dedicati a Squid. Dal canto loro, gli amministratori dovrebbero verificare la versione installata e consultare la documentazione del proprio vendor per confermare la disponibilità delle patch specifiche.