curl, i CVE e quelle severity insensate relative ai bug che creano allarmismi inutili

1

Lo scorso giugno abbiamo raccontato delle perplessità di Daniel Stenberg, creatore di curl, sul National Vulnerability Database (NVD) ed i valori delle CVE e di come in quel caso specifico la CVE-2023-27536, inizialmente inserita con severità 9.8, ossia CRITICAL, ossia Apocalypse now, fosse stata riclassificata, dopo una estenuante serie di azioni, a 5.9, ossia MEDIUM, ossia nulla di che.

Non sono passati che pochi mesi ed ecco una nuova testimonianza di come, in tutta quella storia, poco sia stato imparato. Questa volta è il turno della CVE-2020-19909 indicata in una email alla curl-library mailing list nella quale veniva spiegato come questa non apparisse all’interno del sito di curl.

La faccenda è risultata immediatamente strana per due principali ragioni:

  1. Da sempre il progetto gestisce in autonomia la creazione delle CVE, mentre in questo caso non è stato possibile risalire a chi sia stato ad aprire la segnalazione.
  2. La data della problematica risale, come evoca il nome, al 2020!

La CVE in sé, come spiega Stenberg, non è nulla di che, un integer overflow difficile da spiegare ancor più che sfruttare, già indirizzato e risolto oltre quattro anni fa e presente dalla versione 7.66.0 di curl, datata settembre 2019.

Peccato che al problema sia stato dato un peso di 9.8 CRITICAL, una cosa che neanche le password in chiaro in /etc/passwd forse hanno ed il protagonista, ahi noi, è sempre lo stesso: NVD, ossia il National Vulnerability Database che si preoccupa di catalogare e rendere disponibili i dettagli delle vulnerabilità.

Nonostante quindi sia stato ampiamente dimostrato come la vulnerabilità non sia di tale criticità, nonostante Ubuntu abbia indicato i propri sistemi come non affetti dal problema, la richiesta di Stenberg al MITRE di cancellazione è stata respinta, con questa motivazione:

After review there are multiple perspectives on whether the issue information is helpful to consumers of the CVE List, our current preference is in the direction of keeping the CVE ID assignment. There is a valid weakness (integer overflow) that can lead to a valid security impact (denial of service, based on retrying network traffic much more often than is documented/requested). The record has been flagged as DISPUTED and the views have been recorded as a NOTE in the record as well. This request will now be closed.

Dopo la revisione ci sono molteplici prospettive sull’utilità delle informazioni sul problema per i consumatori dell’elenco CVE, la nostra preferenza attuale è nella direzione di mantenere l’assegnazione dell’ID CVE. Esiste un valido punto debole (integer overflow) che può portare a un impatto valido sulla sicurezza (denial of service, basata sul ritentare il traffico di rete molto più spesso di quanto documentato/richiesto). Il record è stato contrassegnato come CONTROVERSO e anche le visualizzazioni sono state registrate come NOTA nel record. Questa richiesta verrà ora chiusa.

Quindi grazie, ma no grazie.

Ci salveremo mai da queste cose? Verrà mai anteposto il buonsenso alla burocrazia? Oggi siamo un pochino più pessimisti sul tema.

Da sempre appassionato del mondo open-source e di Linux nel 2009 ho fondato il portale Mia Mamma Usa Linux! per condividere articoli, notizie ed in generale tutto quello che riguarda il mondo del pinguino, con particolare attenzione alle tematiche di interoperabilità, HA e cloud.
E, sì, mia mamma usa Linux dal 2009.

Una risposta a “curl, i CVE e quelle severity insensate relative ai bug che creano allarmismi inutili”

  1. Avatar JustATiredMan
    JustATiredMan

    Burocrazia e buonsenso è un ossimoro. Non andranno MAI assieme… D’altronde ne abbiamo una dimostrazione tutti i giorni guardando al nostro miserrimo paese.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *