Falle critiche Linux pubblicate per errore prima delle patch: due permettono RCE

Una serie di vulnerabilità nel kernel Linux, alcune delle quali potenzialmente sfruttabili per eseguire codice da remoto od ottenere privilegi elevati, è finita pubblicamente sulla Linux Kernel Mailing List (LKML) prima che gli sviluppatori completassero le correzioni. La divulgazione, avvenuta tra il 21 e il 22 ottobre, riguarda almeno 6 problemi di sicurezza individuati dalla Zero Day Initiative (ZDI) di Trend Micro. Due delle falle presentano un punteggio CVSS di 9,0 su 10 e interessano componenti che gestiscono le comunicazioni di rete e la condivisione dei file.

L’episodio è particolarmente delicato perché coinvolge il meccanismo attraverso cui il progetto Linux riceve, analizza e corregge le segnalazioni di sicurezza.

Fin dalle prime versioni del kernel, la collaborazione tra sviluppatori si basa su mailing list pubbliche, nelle quali chiunque può esaminare patch, proporre modifiche e partecipare alle discussioni tecniche. Le vulnerabilità non ancora corrette seguono però un percorso differente: gli sviluppatori possono discuterle inizialmente attraverso canali riservati, riducendo il rischio che informazioni sufficienti a costruire un exploit raggiungano eventuali aggressori prima della disponibilità di una correzione.

Greg Kroah-Hartman, uno dei principali manutentori del kernel Linux e responsabile delle versioni stabili, è intervenuto chiedendo chiarimenti sulla pubblicazione, da parte di ZDI, dei dettagli tecnici nella mailing list pubblica.

Perché la pubblicazione anticipata delle vulnerabilità Linux è un problema

La Linux Kernel Mailing List rappresenta uno dei principali strumenti di coordinamento del progetto Linux. I messaggi che transitano sulle liste pubbliche finiscono in archivi consultabili da chiunque, spesso indicizzati da motori di ricerca e sistemi automatici di monitoraggio. Una volta pubblicato un rapporto contenente dettagli tecnici su una vulnerabilità, ormai i buoi sono usciti dalla stalla ed è impossibile rimediare.

La procedura ufficiale per segnalare problemi di sicurezza, descritta nella documentazione del kernel Linux, prevede il coinvolgimento dei manutentori dei componenti interessati e, quando necessario, del team raggiungibile all’indirizzo privato security@kernel.org. Lo scopo non è nascondere i problemi, ma consentire agli sviluppatori di verificarli, preparare una correzione affidabile e coordinare gli aggiornamenti con chi distribuisce il kernel.

Il concetto di divulgazione responsabile non implica la necessità di attendere mesi prima di rendere pubblica una lacuna di sicurezza. L’obiettivo è invece evitare che la descrizione tecnica di una falla raggiunga potenziali aggressori quando gli amministratori non dispongono ancora di strumenti affidabili per proteggersi.

Due vulnerabilità critiche nel sottosistema SMB: possibile esecuzione di codice da remoto

I problemi più gravi tra quelli segnalati interessano il supporto alle comunicazioni SMB, protocollo utilizzato per condividere file e altre risorse attraverso la rete. Linux dispone di implementazioni SMB con ruoli differenti: il client consente di accedere a condivisioni remote, mentre il server integrato nel kernel, KSMBD, permette di offrire condivisioni SMB senza ricorrere necessariamente a un server Samba tradizionale.

La prima segnalazione, identificata come ZDI-CAN-33549, riguarda il supporto SMB Direct, tecnologia che sfrutta RDMA (Remote Direct Memory Access) per trasferire dati riducendo il coinvolgimento della CPU e il numero di copie in memoria.

SMB Direct trova applicazione soprattutto nelle infrastrutture che richiedono elevata velocità di trasferimento e bassa latenza. Invece di far transitare ogni operazione attraverso il normale percorso di rete gestito dalla CPU, RDMA permette alle schede di rete compatibili di accedere direttamente ad aree di memoria opportunamente registrate.

La vulnerabilità in questione, che deriva da un integer underflow, può consentire l’esecuzione di codice da remoto, con una gravità CVSS pari a 9,0.

La seconda vulnerabilità, ZDI-CAN-33774, interessa invece KSMBD e deriva da una race condition: anche in questo caso il punteggio CVSS comunicato raggiunge 9,0 e il possibile impatto comprende l’esecuzione di codice da remoto.

Una race condition nasce quando il comportamento di un programma dipende dall’ordine temporale con cui operazioni concorrenti accedono a una risorsa condivisa. Nel kernel, dove numerosi thread possono lavorare simultaneamente su strutture dati comuni, un problema di sincronizzazione può provocare accessi a oggetti già liberati, modifiche non coordinate o alterazioni dello stato interno.

Le altre vulnerabilità: rete, driver VMware e archiviazione NVMe

Le altre quattro vulnerabilità segnalate da ZDI interessano componenti differenti del kernel Linux.

La falla ZDI-CAN-33367 riguarda la funzione skb_zerocopy, utilizzata nella gestione dei pacchetti di rete per ridurre le copie dei dati in memoria: potrebbe consentire un’escalation locale dei privilegi. Il problema coinvolge un meccanismo di ottimizzazione delle comunicazioni di rete, non un servizio direttamente accessibile da Internet.

Un’altra segnalazione, ZDI-CAN-34068, interessa invece il driver grafico vmwgfx, utilizzato nelle macchine virtuali VMware: un errore di tipo out-of-bounds write potrebbe permettere a un attaccante locale di alterare aree di memoria del kernel e ottenere privilegi superiori.

La vulnerabilità ZDI-CAN-34076 riguarda il componente nvmet, che implementa le funzionalità server di NVMe-over-Fabrics, tecnologia per l’accesso a dispositivi di archiviazione NVMe attraverso la rete. In questo caso, l’utilizzo di una risorsa non inizializzata potrebbe provocare una divulgazione di informazioni.

Infine, ZDI-CAN-32005 interessa la gestione di query TCP e domini di ricerca: un possibile stack buffer overflow potrebbe favorire un’ulteriore escalation locale dei privilegi.

Le 4 falle hanno caratteristiche e condizioni di sfruttamento differenti; la loro presenza nel codice sorgente Linux non implica che ogni installazione sia vulnerabile. L’effettiva esposizione dipende dalle versioni del kernel, dai componenti abilitati e dalle funzionalità utilizzate.

Greg Kroah-Hartman sbotta: perché divulgare le falle prima di correggerle?

A far discutere, più ancora della gravità delle vulnerabilità, è stata la reazione di Greg Kroah-Hartman.

Il manutentore del kernel Linux non ha nascosto il proprio disappunto per la scelta di Trend Micro di inviare le segnalazioni direttamente alle mailing list pubbliche, anziché utilizzare i canali riservati previsti per i problemi di sicurezza.

Kroah-Hartman è intervenuto ripetutamente nelle discussioni, chiedendo spiegazioni sul motivo di una divulgazione tanto anticipata. La sua reazione lascia trasparire una certa irritazione: perché rendere note vulnerabilità potenzialmente critiche quando le relative patch non sono ancora disponibili nel ramo principale del kernel?

Il problema ha a che fare, come accennato nell’introduzione, con il coordinamento tra ricercatori e sviluppatori. Una segnalazione pubblica può infatti mettere gli aggressori nella condizione di analizzare immediatamente il codice vulnerabile, mentre chi gestisce i sistemi deve attendere la disponibilità delle correzioni.

In alcuni casi gli sviluppatori avevano già preparato delle patch o stavano lavorando autonomamente agli stessi problemi.

La pubblicazione dei rapporti ZDI rischia quindi di trasformare una normale attività di manutenzione della sicurezza in una corsa contro il tempo. Al momento non è chiaro se Trend Micro abbia commesso un errore nell’invio delle comunicazioni o abbia scelto deliberatamente la divulgazione pubblica.