CVE, cosa sono e perché la classificazione delle vulnerabilità non è sempre affidabile

La sigla CVE sta per Common Vulnerabilities and Exposures: si tratta di identificativi univoci assegnati alle varie vulnerabilità software, indipendentemente dalla piattaforma, dal prodotto o dal fornitore coinvolti. Un CVE potrebbe ad esempio apparire come CVE-2023-12345. Nella prima parte dell’identificativo figura l’anno in cui è stato scoperto il problema di sicurezza; nella seconda c’è un numero che si riferisce alla specifica vulnerabilità.

L’obiettivo principale dei CVE è facilitare la condivisione e la comunicazione delle informazioni sulle vulnerabilità tra gli sviluppatori software, gli esperti di sicurezza e gli utenti finali. Al momento della scoperta di una vulnerabilità, l’assegnazione di un CVE univoco e la condivisione di informazioni dettagliate sulla natura della vulnerabilità, sulle sue potenziali conseguenze e sulle contromisure consigliate, aiuta l’intera comunità a prendere coscienza del problema ponendo in essere gli interventi più opportuni.

Cos’è il National Vulnerability Database (NVD) e cosa c’entra curl

Il National Vulnerability Database (NVD) è un database gestito dal National Institute of Standards and Technology (NIST) negli USA. Si tratta di una risorsa pubblica che raccoglie e archivia informazioni dettagliate su vulnerabilità software condividendo uno specifico CVE per ciascuna delle lacune di sicurezza via via identificate.

NVD rende disponibili i dati sulle vulnerabilità attraverso il proprio database e i propri feed di dati. In questo modo i professionisti della sicurezza informatica, gli sviluppatori di software e gli utenti finali possono restare costantemente informati.

Raccontando la sua recente esperienza, che si pone sulla stessa scia di altri episodi registratisi in passato, l’autore del popolarissimo software curl, applicazione che facilita il trasferimento dei file, critica aspramente il comportamento di NVD e le modalità con cui i CVE sono gestiti.

Nato nel 1998, si calcola che curl è complessivamente utilizzato in circa 20 miliardi di installazioni. Da software libero e open source, il progetto curl pubblica e aggiorna tempestivamente l’elenco delle problematiche di sicurezza scoperte nel programma.

Daniel Stenberg, ideatore di curl, racconta di aver subito sentito puzza di bruciato quando uno dei responsabili del NVD lo ha contattato per informarlo dell’apertura di un nuovo CVE, contraddistinto con l’identificativo CVE-2020-19909. Nella descrizione della problematica si parla di un grave problema di “Integer Overflow or Wraparound” (9,8 punti su un massimo di 10 in termini di gravità) scoperto all’interno di curl.

Con “Integer Overflow or Wraparound” si fa riferimento a una vulnerabilità di sicurezza che si verifica quando una variabile di tipo intero supera il suo valore massimo consentito per tornare quindi al minimo valore possibile, causando risultati imprevisti o pericolosi.

L’autore di curl contesta le modalità di gestione delle CVE da parte del National Vulnerability Database (NVD)

Ciò che ha immediatamente insospettito Stenberg è la presenza del valore “2020” nella denominazione della falla appena scoperta. Ma come? Un problema di sicurezza individuato nel 2020 diventa di pubblico dominio soltanto oggi?

Andando in profondità, lo sviluppatore di curl ha ricollegato CVE-2020-19909 a una segnalazione che era arrivata a luglio 2019 ma che dimostrò non essere affatto un problema di sicurezza.

Stenberg cita il comando curl --retry-delay 18446744073709552 .... Si tratta di una richiesta che prevede l’esecuzione di curl, con un ritardo per i successivi ritentativi di connessione, particolarmente lungo. L’intero indicato è vicino al valore massimo rappresentabile usando 64 bit. Per questo motivo, possono presentarsi anomalie in casi specifici ma non certo problemi di sicurezza.

Per questo motivo l’autore di curl ha corretto il bug in una versione successiva della sua utilità e chiuso la segnalazione.

Non c’è alcun problema di sicurezza in curl e lo sviluppatore dell’utilità si scaglia contro NVD

Oggi la stessa problematica torna in auge sul database di NVD, addirittura dipinta come a elevata criticità. Così Stenberg si è scagliato contro l’attuale sistema di gestione dei CVE raccontando di aver cercato di “ragionare con NVD e fermare il loro allarmismo e il loro grossolano aumento del livello di gravità dei problemi“. E ancora: “NVD in realtà non si sforza di comprendere o capire effettivamente il problema che classifica. (…) È del tutto impossibile per me capire come possano arrivare a questo livello di gravità. È come se avessero visto un Integer Overflow e avessero pensato che ‘wow, sì, questo è il difetto più orribile che possiamo immaginare’. Chiaramente nessuno in NVD si è impegnato con il cervello né ha verificato il codice “vulnerabile” o la patch che ha corretto il bug. Chiunque faccia un controllo può rendersi conto che questo non è un problema di sicurezza“.

Insomma, secondo Stenberg le modalità di verifica del contenuto delle segnalazioni andrebbero attentamente verificate prima di pubblicare un CVE. E lo conferma anche nella pagina di supporto sulle tematiche di sicurezza: “Nel database NVD utilizzano livelli di gravità e punteggi CVSS gonfiati. Pensano di saperne di più e ignorano le nostre valutazioni. Questo è un errore sistemico che purtroppo non possiamo correggere. Sentitevi liberi di lamentarvi con loro – noi continuiamo a farlo inutilmente – e considerate l’utilizzo del nostro materiale come riferimento per i problemi di curl“.

Il fatto è che il database CVE di NVD è ancora oggi assunto come riferimento da un numero incalcolabile di fonti. L’indicazione fasulla sulla presenza di una grave vulnerabilità all’interno di curl danneggia l’immagine e le attività degli sviluppatori software. Fortunatamente, alcuni soggetti come Canonical hanno già fatto proprie le eccezioni sollevate da Stenberg ma il problema, in ottica futura, non riguarda una singola utilità (seppur popolarissima come curl) ma ha direttamente a che fare con l’intera platea delle applicazioni distribuite attraverso qualsivoglia canale. E d’ora in avanti, sul piano della classificazione delle vulnerabilità di sicurezza, qualcosa deve necessariamente cambiare. In meglio.

Credit immagine in apertura: iStock.com/Olemedia