Di quanto il creatore di curl, Daniel Stenberg, abbia cercato di contrastare l’uso malsano che viene fatto delle CVE abbiamo parlato a lungo. Poco più di un mese fa l’ultima volta, a proposito di come il National Vulnerability Database (NVD) avesse assegnato ad una vulnerabilità ininfluente un valore pazzesco.

Il messaggio che si voleva passare però era solo relativo a come la logica e l’obiettività siano punti fondamentali nel valutare le vulnerabilità, poiché se una cosa emerge chiara dalla notizia che stiamo riportando è che il progetto curl tratta la sicurezza in maniera decisamente seria.

Ne è dimostrazione il recente articolo How I made a heap overflow in curl, dove l’autore di curl racconta di una problematica reale e molto grave, a cui è stata assegnata la severity HIGH.

I dettagli dell’anomalia sono spiegati dettagliatamente all’interno dell’articolo, ma è sufficiente menzionare come questa sia ritenuta la peggior falla di sicurezza relativa a curl in molto tempo e che, proprio per questo, sono state usate tutte le cautele possibili:

I cannot disclose any information about which version range that is affected, as that would help identify the problem (area) with a very high accuracy so I cannot do that ahead of time. The “last several years” of versions is as specific as I can get.

Non posso rivelare alcuna informazione su quale gamma di versioni sia interessata, in quanto ciò potrebbe aiutare a identificare il problema (area) con una precisione molto elevata, quindi non posso farlo in anticipo. Gli “ultimi anni” delle versioni sono quanto di più specifico posso ottenere.

Una scelta che a prima vista potrebbe sollevare delle perplessità, tanto che, alla richiesta di un utente sulla issue:

When there is a HIGH CVE security flaw, why then not release immediately after fix has been applied, but at a set date? (Now, exploit-hunters are aware that there is something and have 7 days notice in which they can focus intensely on curl to find the flaw and exploit it.)

Quando c’è una falla di sicurezza CVE HIGH, perché non rilasciarla immediatamente dopo l’applicazione della patch, invece che ad una data prestabilita? (Ora i cacciatori di exploit sono consapevoli che c’è qualcosa e hanno 7 giorni di preavviso in cui possono concentrarsi intensamente su curl per trovare il difetto e sfruttarlo.)

Stenberg ha risposto in questo modo:

I set the date to

– allow us a few days for more deliberating on the vulnerability, to really think it through, write the advisory, understand it proper. Rinse and repeat.
– give “distro people” a few days to prepare patched updates
– allow a few days for the project (and me) to line up things to prepare for the new release
– we can spread the word about the pending release and the main reason for it in the mean time
– the release needs to work with my personal schedule and Wednesdays are our standard release days

Sure, there is a minuscule risk that someone can find this (again) before we ship the patch, but this issue has stayed undetected for years for a reason. I think taking a few days to make sure we do a solid release is worth this risk.

Ho impostato la data per:

– concederci qualche giorno per riflettere ulteriormente sulla vulnerabilità, per rifletterci davvero, scrivere l’avviso e comprenderlo correttamente. Risciacqua e ripeti.
– dare ai gestori delle distribuzioni qualche giorno per preparare gli aggiornamenti con patch
– concedere qualche giorno al progetto (e a me) per mettere in fila le cose per prepararsi alla nuova versione
– spargere la voce sull’imminente rilascio e sul motivo principale il rilascio
deve rispettare il mio programma personale e il mercoledì è il nostro giorno di rilascio standard

Certo, c’è un minuscolo rischio che qualcuno possa trovarlo (nuovamente) prima che spediamo la patch, ma questo problema non è stato rilevato per anni per un motivo. Penso che prendersi qualche giorno per assicurarsi di fare un rilascio solido valga questo rischio.

La versione 8.4.0 di curl, che risolve la problematica, è già disponibile ed ovviamente è consigliabile per tutti aggiornare.

La sostanza del discorso è: calma e gesso. E rappresenta anche il perché riportiamo questa notizia, apprezzando la coerenza di comportamento a fronte di una problematica giudicata grave, all’interno di un progetto che al momento conta 3000 contributori, ma per il quale possiamo stare tranquilli, poiché è decisamente in buone mani.

Raoul Scarazzini

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.