In questo articolo Indice dei contenuti 3 sezioni
Una serie di vulnerabilità nel kernel Linux è finita in chiaro sulla Linux Kernel Mailing List (LKML) prima che gli sviluppatori riuscissero a completare le correzioni, e almeno due di queste falle potrebbero permettere l’esecuzione di codice da remoto. La pubblicazione è avvenuta tra il 21 e il 22 ottobre e riguarda almeno sei problemi di sicurezza individuati dalla Zero Day Initiative (ZDI) di Trend Micro. Le due lacune più gravi hanno ottenuto un punteggio CVSS di 9,0 su 10 e coinvolgono componenti dedicati alle comunicazioni di rete e alla condivisione dei file.
La vicenda è delicata perché tocca il meccanismo con cui il progetto riceve, analizza e sistema le segnalazioni. Da sempre lo sviluppo del kernel Linux si appoggia a mailing list pubbliche dove chiunque può esaminare patch, proporre modifiche e partecipare alle discussioni tecniche. Le vulnerabilità non ancora corrette seguono però un percorso diverso, perché possono essere discusse prima in canali riservati, così da ridurre il rischio che informazioni utili a costruire un exploit arrivino a eventuali aggressori prima che esista una correzione. Greg Kroah Hartman, tra i principali manutentori del kernel e responsabile delle versioni stabili, è intervenuto chiedendo conto a ZDI della pubblicazione dei dettagli tecnici sulla lista pubblica.
Perché una divulgazione anticipata crea problemi
La Linux Kernel Mailing List è uno degli strumenti di coordinamento più importanti del progetto. I messaggi che vi transitano finiscono in archivi consultabili da chiunque, spesso indicizzati dai motori di ricerca e da sistemi automatici di monitoraggio. Una volta uscito un rapporto con i dettagli tecnici di una falla, i buoi sono ormai scappati dalla stalla e rimediare diventa impossibile.
La procedura ufficiale descritta nella documentazione prevede di coinvolgere i manutentori dei componenti interessati e, quando serve, il team raggiungibile all’indirizzo privato security@kernel.org. Lo scopo non è nascondere i difetti ma dare modo agli sviluppatori di verificarli, preparare una correzione affidabile e coordinare gli aggiornamenti con chi distribuisce il sistema. La divulgazione responsabile non significa aspettare mesi prima di rendere pubblico un problema. Serve piuttosto a evitare che la descrizione di una falla raggiunga potenziali attaccanti quando gli amministratori non hanno ancora strumenti concreti per difendersi.
Le due falle critiche in SMB e gli altri difetti
I problemi più seri riguardano il supporto a SMB, il protocollo usato per condividere file e altre risorse in rete. Linux dispone di un client per accedere a condivisioni remote e di un server integrato nel kernel, KSMBD, che permette di offrire condivisioni senza ricorrere per forza a Samba. La prima falla colpisce SMB Direct, tecnologia che sfrutta RDMA (Remote Direct Memory Access) per spostare dati riducendo il lavoro della CPU e il numero di copie in memoria. Viene impiegata soprattutto dove servono alta velocità e bassa latenza, perché consente alle schede di rete compatibili di accedere direttamente ad aree di memoria registrate. Qui il difetto nasce da un integer underflow e può portare all’esecuzione di codice da remoto, con gravità 9,0. La seconda vulnerabilità tocca invece KSMBD e deriva da una race condition, cioè una situazione in cui il comportamento del programma dipende dall’ordine con cui operazioni concorrenti accedono a una risorsa condivisa. Nel kernel, dove molti thread lavorano insieme sulle stesse strutture dati, un errore di sincronizzazione può causare accessi a oggetti già liberati o alterazioni dello stato interno. Anche in questo caso il punteggio è 9,0.
Le altre quattro vulnerabilità nel kernel Linux sono di natura diversa. Una riguarda la funzione skb_zerocopy, usata nella gestione dei pacchetti di rete, e potrebbe consentire un’escalation locale dei privilegi senza però esporre un servizio raggiungibile da Internet. Un’altra colpisce il driver grafico vmwgfx delle macchine virtuali VMware, dove una scrittura fuori dai limiti della memoria permetterebbe a un attaccante locale di ottenere privilegi superiori. C’è poi nvmet, che implementa la parte server di NVMe over Fabrics per accedere a dispositivi di archiviazione attraverso la rete, con una risorsa non inizializzata che potrebbe far trapelare informazioni. L’ultima tocca la gestione di query TCP e domini di ricerca, dove uno stack buffer overflow aprirebbe a un’altra escalation locale. La presenza di questi errori nel codice non rende vulnerabile ogni installazione, perché tutto dipende da versione, componenti abilitati e funzioni effettivamente in uso.
L’irritazione di Greg Kroah Hartman
Più della gravità delle falle ha fatto rumore la reazione di Greg Kroah Hartman, che non ha nascosto il disappunto per la scelta di Trend Micro di inviare i rapporti alle liste pubbliche invece di usare i canali riservati. Il manutentore è intervenuto più volte chiedendo perché rendere note vulnerabilità potenzialmente critiche quando le patch non erano ancora presenti nel ramo principale. Una segnalazione pubblica permette agli aggressori di studiare subito il codice difettoso mentre chi gestisce i sistemi deve aspettare le correzioni. In alcuni casi gli sviluppatori avevano già preparato delle patch o stavano lavorando per conto proprio sugli stessi problemi, ma la pubblicazione dei rapporti ZDI rischia di trasformare una normale manutenzione in una corsa contro il tempo. Al momento non è chiaro se Trend Micro abbia sbagliato l’invio delle comunicazioni o abbia scelto deliberatamente la strada della divulgazione pubblica.
Fonte: TecnoAndroid