Nei giorni scorsi si è consumato un siparietto su VLC, che però ben illustra i meccanismi di allarme e risoluzione per i bug di sicurezza. Ma andiamo con ordine.
Il 24 luglio sul sito tedesco CERT Bund – dedicato alla sicurezza – compare un report per l’ultima versione di VLC, la 3.0.7.1, e per tutte le piattaforme, Linux, UNIX, Windows; c’è tanto di link ad una CVE aperta una settimana prima al database nazionale americano.
Il problema? Sfruttando una falla un malintenzionato potrebbe eseguire qualsiasi codice da remoto.
Il baco sembra di quelli seri, e se si considera che VLC è probabilemte il riproduttore multimediale più usato sulle piattaforme linux, ma molto diffuso anche su Windows, si capisce la dimensione. Se poi aggiungiamo che la versione indicata come vulnerabile è proprio l’ultima disponibile, l’urgenza diventa evidente.
E infatti molte testate riprendono l’allarme e ne danno notizia.
Ma possibile che gli sviluppatori di VLC non sapessero nulla? Beh, sì, possibile, perché chi ha fatto partire il tutto si è limitato ad aprire un bug sul tracker di VLC, ma non ha avvertito il team sicurezza. E quindi è stato trattato come gli altri bug: assegnato ad uno sviluppatore, che tenta di replicare l’errore per identificarlo e valutarlo, e infine (forse) risolverlo. Processo lungo, iniziato quasi un mese prima, ma che ancora non ha alzato alcun allarme.
Gli articoli di giornale puntano i riflettori su questo bug, e cominciano frenetici i lavori. Che all’inizio non portano a nulla.
Sorry, but this bug is not reproducible and does not crash VLC at all.
Mi dispiace, ma questo bug non è riproducibile e non rompe affatto [l’esecuzione di] VLC.
Siamo a ieri, e l’utente che ha aperto il bug insiste; gli viene risposto di rivolgersi al gruppo sicurezza.
There is a dedicated security@ contact information if you want to discuss about that.
Esiste il contatto dedicato security@ se vuoi discuterne.
A public bugtracker is not the right place.
Un tracker di bug pubblico non è il posto giusto.
A questo punto è già chiaro che la segnalazione è quantomeno imprecisa. E infatti, qualche ora dopo, si risolve il mistero: una libreria vecchia di Ubuntu 18.04, usata dall’autore del bug.
Issue is too old libebml in Ubuntu 18.04: libebml 1.3.6 fixes this issue. End of story: VLC is not vulnerable, whether this is 3.0.7.1 or even 3.0.4. The issue is in a 3rd party library, and it was fixed in VLC binaries version 3.0.3, out more than one year ago…
Il problema è una versione troppo vecchia di libebml in Ubuntu 18.04: libebml 1.3.6 risolve questo problema. Fine della storia: VLC non è vulnerabile, che sia la versione 3.0.7.1 o anche la 3.0.4. Il problema è in una libreria di terze parti, ed è stata sistemata nei binari di VLC versione 3.0.3, più di un anno fa…
Quindi, in definitiva, il problema è in librerie sorpassate di Ubuntu, che nella versione LTS, mantiene la versione di libreria integrando solo fix di sicurezza. Forse.
Il consiglio è il solito: aggiornate, aggiornate, aggiornate.
Ma questa storia insegna anche altro, ovvero che le segnalazioni sono essenziali, purché fatte nel modo giusto.
Abbiamo anche un esempio di come le distribuzioni LTS sono preziose (financo essenziali) per chi lavora in ambito enterprise e server, ma meno indicate per il desktop personale, per il cui uso le distribuzioni “normali” vanno più che bene. Anche senza arrivare alle distribuzioni rolling release – sempre all’ultimissima versione!
Ho coltivato la mia passione per l’informatica fin da bambino, coi primi programmi BASIC. In età adulta mi sono avvicinato a Linux ed alla programmazione C, per poi interessarmi di reti. Infine, il mio hobby è diventato anche il mio lavoro.
Per me il modo migliore di imparare è fare, e per questo devo utilizzare le tecnologie che ritengo interessanti; a questo scopo, il mondo opensource offre gli strumenti perfetti.
Lascia un commento