Vulnerabilità in curl: esiste davvero e riguarda il supporto SOCKS5

Questa volta la vulnerabilità curl c’è ed esiste davvero. A confermarlo è l’ideatore della nota utilità, Daniel Stenberg, che in una nota apparsa su GitHub qualche giorno fa annunciava l’esistenza di un problema.

Oggi Stenberg e il suo team, così come preannuciato, hanno rilasciato la versione 8.4.0 di curl. Si tratta di una release che altre software house chiamerebbero out-of-band: la gravità delle problematiche di sicurezza emerse ha infatti spinto alla distribuzione emergenziale, in tempi brevissimi, di un aggiornamento correttivo.

L’autore di curl osserva che le vulnerabilità individuate sono due: la prima è una delle più severe mai riscontrate nel programma da anni e anni a questa parte.

Perché le vulnerabilità curl sono così serie

Iniziamo col dire che curl è un’utilità eccellente, che non conosce confini. Nata nel lontano 1998, curl facilita il trasferimento di file in qualunque ambito. In un altro articolo abbiamo messo in evidenza le differenze tra curl e wget spiegando che il primo è un software molto più completo e versatile, che supporta decine di protocolli diversi, l’upload di file, i proxy, l’autenticazione, l’invio di dati con vari metodi (POST, PUT,…) e un ampio ventaglio di funzionalità avanzate.

Si calcola che curl è complessivamente utilizzato in circa 20 miliardi di installazioni a livello globale. Oltre all’utilità da riga di comando, infatti, tanti software e prodotti hardware integrano la libreria libcurl. Si tratta di un componente che fornisce funzionalità di trasferimento di file tramite URL. Scritta in C, offre un’interfaccia di programmazione (API) per eseguire operazioni di trasferimento dati tramite vari protocolli.

Le caratteristiche principali di libcurl includono la gestione dei cookie, il supporto per HTTP/2 e HTTP/3, per le connessioni sicure tramite SSL/TLS, la possibilità di utilizzare proxy e altro ancora. Inoltre, la libreria è progettata per essere portabile e multi piattaforma.

Dato che libcurl è una libreria a basso livello, è spesso integrata in applicazioni di più alto livello per fornire funzionalità di trasferimento dati. Molti linguaggi di programmazione forniscono strumenti per l’integrazione diretta dei progetti con la libreria libcurl, consentendo agli sviluppatori di utilizzarla facilmente nelle loro applicazioni.

È evidente qual è il nocciolo del problema: poiché la vulnerabilità più pericolosa interessa sia l’utilità curl che la libreria libcurl, è essenziale che tutte le distribuzioni, tutti i progetti che la integrano, tutti i prodotti hardware e software, tutti gli utenti passino alla release 8.4.0 più aggiornata. Quanti dispositivi del mondo Internet delle Cose (IoT) usano curl? Un’infinità.

Quali sono le vulnerabilità scoperte in curl

Stenberg aveva recentemente contestato la classificazione delle vulnerabilità nel database NVD. Questa volta, però, è lui stesso a preparare le parti interessate al problema.

La vulnerabilità CVE-2023-38545 è classificata infatti come critica e, come detto, interessa sia lo strumento curl che libcurl. Il secondo problema di sicurezza, CVE-2023-38546, desta invece molta meno preoccupazione e riguarda solo libcurl.

Gli sviluppatori del progetto curl hanno atteso qualche giorno prima di pubblicare curl 8.4.0 per via dell’impatto significativo sulla sicurezza di un vastissimo numero di prodotti hardware e software. Soltanto i responsabili di alcune community, ad esempio i gestori delle distribuzioni Linux, conoscevano i dettagli sulle vulnerabilità venute a galla in curl.

Il problema più importante riguarda l’implementazione del protocollo SOCKS5

SOCKS5 è un protocollo proxy che permette di impostare le comunicazioni di rete tramite un “intermediario” dedicato. Il protocollo è di solito utilizzato quando si imposta la comunicazione tramite Tor Browser ma anche per abilitare l’accesso a Internet dall’interno di organizzazioni e aziende.

Questo protocollo prevede due diverse modalità di risoluzione dei nomi host: Stenberg spiega che l’implementazione di SOCKS5 in curl soffriva di un difetto che, in alcuni casi, espone a rischi di heap overflow. Un aggressore che controlla un server HTTPS utilizzato dalla libreria libcurl e raggiunto attraverso proxy SOCKS5, può girare al client un header “confezionato” ad arte che – in alcune circostanze – può causare un errore di buffer overflow.

Un heap buffer overflow è una vulnerabilità di sicurezza che si ha quando un programma, durante l’esecuzione, scrive dati al di là dei limiti di un buffer allocato dinamicamente nell’heap della memoria. L’heap è una regione di memoria utilizzata dai programmi per l’allocazione dinamica dei dati. L’overflow si verifica quando i dati sono scritti oltre i limiti dell’area di memoria riservata. La conseguenza sono comportamenti imprevisti e, addirittura, l’esecuzione di codice arbitrario.

“Leggendo ora il codice è impossibile non vedere il bug“, ammette Stenberg. “Sì, è davvero doloroso dover accettare il fatto di aver commesso questo errore senza accorgermene e che il difetto sia rimasto nascosto nel codice per 1315 giorni. Chiedo scusa. Non sono altro che un essere umano“.

L’ideatore di curl precisa comunque che, per quanto lo riguarda, il codice di curl resterà scritto in C. La sicurezza della memoria nelle applicazioni è un problema oggi sempre più sentito ma, come ricorda Stenberg, quando egli iniziò a sviluppare curl, l’idea alla base di Rust non era neppure nei sogni degli sviluppatori più avveduti. E invita tutti coloro che non sono contenti della sua posizione, a collaborare mettendosi al lavoro in prima persona.