È apparso recentemente un post dalla mailing list OSS Security dal titolo piuttosto inquietante, 432 Linux kernel CVEs, in cui l’autore, Jan Schaumann, nell’osservare le tempistiche si è detto decisamente allarmato, poiché tutte quelle CVE sono state rilasciate in poco più di 24 ore.

Un numero così elevato, fa notare l’autore, denota una problematica di fondo relativa alle modifiche di sicurezza, ed in particolare relativamente alla priorità delle stesse: con un numero così alto, con quale criterio è possibile decidere cosa debba essere fatto prima e cosa dopo? Concludendo con un laconico:

I'm not sure what to do here going forward.

Non sono sicuro di cosa fare d’ora in poi.

La vicenda fa seguito a quanto abbiamo raccontato non molto tempo fa, con Linus Torvalds in persona a lamentarsi del catastrofico numero di bug segnalati mediante AI, e chiaramente questa pioggia di CVE è sicuramente frutto di analisi simili. Tuttavia, il creatore di Linux ha recentemente dichiarato come l’IA sia uno strumento utile per lo sviluppo di Linux, pur evidenziando come la vita per i manutentori, proprio per quei bug che lui definisce “imbarazzanti”, sia diventata certamente più complicata.

Ma la conclusione, come abbiamo ampiamente detto, è una ed una soltanto: chi non apprezza che nel Kernel Linux ci siano porzioni scritte o gestite con l’IA può “fare un fork, oppure levarsi di torno“.

Ma torniamo alla pioggia di CVE con cui abbiamo aperto questo articolo. Nel thread citato poco sopra ad essere messo in discussione è il ruolo dei team IT e di sicurezza, che devono determinare quali vulnerabilità riguardano i loro sistemi e quali aggiornamenti del Kernel devono essere implementati. A proposito di questo aspetto è intervenuto niente meno che il manutentore senior del Kernel stabile, Greg Kroah-Hartman, che si è opposto all’idea che il volume di CVE del Kernel sia ingestibile. Il Kernel non è speciale, ha scritto: le aziende di tutto il mondo stanno finalmente realizzando di dover rivalutare come aggiornano tutti i loro sistemi e dispositivi, qualcosa che tradizionalmente è stato vergognosamente ignorato.

Kroah-Hartman offre con molta chiarezza il suo punto di vista in merito agli atteggiamenti che i team possono assumere:

• Se l’atteggiamento è “non mi importa, io aggiorno sempre e comunque all’ultima versione“, allora benissimo, è quello che la community degli sviluppatori del Kernel incoraggia e suggerisce.
• Se l’atteggiamento è “mi importa, e voglio fare review di ogni singola CVE per decidere se includerla o no“, allora benissimo, soprattutto se si automatizza la scelta di quali CVE sono appropriate (ed in genere, dice, il numero si riduce sempre al 10%).
• Se, infine, l’atteggiamento è “aggiorno selettivamente quando le vulnerabilità sono talmente grandi da spingere qualcuno a richiedere un update“, ecco, in questo caso la risposta è “buona fortuna!“.

A riprova del fatto che l’approccio suggerito (quello dell’applicazione dell’ultimo aggiornamento disponibile) è scalabile, Kroah-Hartman indica Android come un caso di successo provato e suggerisce l’utilizzo di una distribuzione dietro subscription, o l’utilizzo di Debian, che dice avere delle pratiche di sicurezza eccezionali.

Il tutto, alla luce del fatto che questo diluvio di CVE, avverte Kroah-Hartman, non è affatto finito, e ci vorranno almeno 18 mesi molto lunghi per rientrare nei ranghi, sottolineando ancora una volta come gli utenti dovrebbero aggiornare i propri sistemi lungo tutto il percorso per essere in qualche modo al sicuro.

Ma perché 432 CVE e perché tutti in una volta sola? La risposta qui è semplice: è stato un suo recupero, durante il fine settimana, di una coda di revisione pubblica vecchia di settimane. Dopo 6 settimane di conferenze e vacanze il lavoro si è accumulato ed al rientro dalle ferie ecco servita la doccia di CVE.

Quindi sì, in un certo senso, tutto normale.