Una vulnerabilità riguarda più versioni del Kernel Linux. StackRot (CVE-2023-3269) richiede “capacità minime” per l’attivazione e potrebbe consentire l’escalation dei privilegi.
“La falla StackRot (CVE-2023-3269) è estremamente insidiosa”, mette in guardia Pierluigi Paganini, analista di cyber security e CEO Cybhorus, “in quanto consente ad un attaccante di compromettere il kernel del sistema operativo e di elevare i propri privilegi”.
“Classificata con un CVSS score pari a 7.9, tale vulnerabilità”, conferma Antonio Minnella, Ricercatore Sicurezza di Exprivia, “affligge le versioni del kernel dalla 6.1 alla 6.4 e, se sfruttata con successo, può portare all’esecuzione di codice arbitrario e al privilege escalation fino all’ottenimento dei permessi di
root sulla macchina target”.
Dal primo luglio è disponibile una patch per i kernel stabili interessati, dal momento che l’impatto riguarda le configurazioni del kernel nelle versioni di Linux dalla 6.1 alla 6.4. Ecco come mitigare il rischio.
Indice degli argomenti
Kernel Linux: la nuova falla di StackRot
Il ricercatore di sicurezza Ruihan Li ha scoperto e segnalato la falla nel Kernel Linux. In un post spiega che la vulnerabilità di StackRot riguarda il sottosistema di gestione della memoria del kernel, un componente incaricato di implementare la memoria virtuale e demand paging, l’allocazione della memoria per le esigenze del kernel e dei programmi dello spazio utente, oltre alla mappatura dei file nello spazio degli indirizzi dei processi.
StackRot ha infatti un impatto su tutte le configurazioni del kernel nelle versioni di Linux dalla 6.1 alla 6.4. “A rendere più grave la scoperta della falla è l’annuncio da parte del ricercatore che ha scoperto la vulnerabilità di divulgare i dettagli tecnici e di pubblicare un proof-of-concept (PoC) exploit entro la fine di luglio”, aggiunge Paganini.
Sebbene Li abbia inviato la segnalazione della vulnerabilità a metà giugno, la creazione di una correzione ha richiesto quasi due settimane a causa della sua complessità. “La scoperta risale al 15 giugno scorso e per fixarla ci sono volute due settimane di duro lavoro da parte del rescue team guidato da Linus Torvalds in persona. Lo scorso 28 giugno sono state mergiate su git tutte le modifiche e dal 1 luglio sono disponibili una serie di patch per i kernel ‘stable’ (6.1.37, 6.3.11, 6.4.1)”, commenta Antonio Minnella.
“Il 28 giugno, durante la finestra di fusione per il kernel Linux 5.5, la correzione è stata inserita nell’albero di Linus. Linus ha fornito un messaggio di fusione completo per chiarire la serie di patch da un punto di vista tecnico. Queste patch sono state successivamente riportate nei kernel stabili (6.1.37, 6.3.11 e 6.4.1), risolvendo di fatto il bug ‘Stack Rot’ il 1° luglio”, ha chiarito il ricercatore.
I dettagli tecnici
Entrando nel dettaglio della vulnerabilità, “possiamo constatare che la stessa sia stata introdotta con l’avvento della versione 6.1 del kernel ovvero quando il sottosistema di gestione della memoria virtuale (VMA) è stato modificato da ‘rb tree’ (red-black tree) a ‘maple tree'”, afferma Antonio Minnella: “Maple tree è un B-tree basato su RCU-safe (Read, Copy, Update) progettato allo scopo di
sfruttare al meglio la cache nei processori di ultima generazione”.
“I maple tree offrono una soluzione performante a discapito della complessità di implementazione che, inaspettatamente, ha introdotto la vulnerabilità Stack Rot”, spiega Minnella: “La vulnerabilità è dovuta ad un problema use-after-free (UAF) derivante dalla modalità di gestione dell’espansione dello stack, poichè nell’implementazione maple tree ciò che potrebbe accadere è la sostituzione di un nodo senza ottenere il lock in scrittura della gestione della memoria
(MM)”.
“Sebbene i maple tree vengano liberati utilizzando la callback RCU, ritardando l’effettiva deallocazione della memoria fino alla scadenza della tolleranza RCU. Di conseguenza, lo sfruttamento di questa vulnerabilità è considerato impegnativo.
Ogni volta che la chiamata di sistema mmap() viene utilizzata per stabilire una mappatura della memoria, il kernel genera una struttura chiamata vm_area_struct per rappresentare la corrispondente area di memoria virtuale (VMA). Questa struttura memorizza varie informazioni, tra cui proprietà e altri dettagli relativi alla mappatura”, avverte Minnella: “Questa struttura memorizza varie informazioni, tra cui proprietà e altri dettagli relativi alla mappatura”.
“Di conseguenza”, continua l’espetto di cyber security, “quando il kernel incontra page fault o altre chiamate di sistema relative alla memoria, richiede una rapida ricerca della VMA basata esclusivamente sull’indirizzo.
In sostanza, il maple tree è composto da maple nodes. Assumendo che il maple tree sia composto da un unico nodo radice in grado di contenere un massimo di 16 intervalli, ogni singolo intervallo, a sua volta, può rappresentare un gap o puntare a una VMA. Pertanto, non sono ammessi spazi vuoti tra due intervalli”.
“La struttura maple_range_64 rappresenta un maple tree nel modo seguente. I pivot indicano i punti finali di 16 intervalli, mentre gli slot sono usati per fare riferimento alla struttura VMA quando il nodo è considerato un nodo foglia. La disposizione dei pivot e degli slot può essere visualizzata come segue”.
“Per quanto riguarda la modifica concorrente”, continua Minnella, “il maple tree impone delle restrizioni, richiedendo un lock esclusivo per le scritture. Nel caso dell’albero VMA, il blocco esclusivo corrisponde al blocco di scrittura MM. Per quanto riguarda le letture, sono disponibili due opzioni:
- la prima opzione prevede il mantenimento del blocco di lettura MM, con il risultato che lo scrittore viene bloccato dal blocco di lettura e scrittura MM;
- la seconda opzione consiste nell’entrare nella sezione critica del RCU. In questo modo, lo scrittore non viene bloccato e i lettori possono continuare le loro operazioni poiché il maple tree, come detto, gode del RCU-safe.
Mentre la maggior parte degli accessi VMA esistenti opta per la prima opzione, la seconda viene utilizzata in alcuni scenari critici per le prestazioni, come i page fault senza blocco”.
La logica di espansione dello stack
“Un altro aspetto da tenere in considerazione, riguarda la logica di espansione dello stack. Lo stack rappresenta un’area di memoria mappata con il flag MAP_GROWSDOWN, che implica l’espansione automatica quando si accede a un indirizzo inferiore alla regione. Dunque, in questi casi, l’indirizzo iniziale del VMA corrispondente riceve una modifica, lo stesso accade per l’intervallo associato all’interno maple tree. In particolare, queste modifiche si effettuano senza mantenere il blocco di scrittura MM”.
“Inoltre, in genere, esiste uno spazio tra la VMA dello stack e la VMA adiacente, poiché il kernel applica una protezione dello stack. In questo scenario, quando si espande lo stack, è necessario aggiornare solo il valore del pivot nel nodo del maple. Tale processo può essere eseguito atomicamente. Occorre altresì prestare attenzione poiché, se anche il VMA adiacente ha il flag MAP_GROWSDOWN, non c’è applicazione di alcuna protezione dello stack. Di conseguenza, l’espansione dello stack può causare l’eliminazione del gap. In queste situazioni, l’intervallo di gap all’interno del nodo maple deve essere rimosso. Poiché il maple tree è RCU-safe, non è possibile sovrascrivere il nodo in-place. Al contrario, viene creato un nuovo nodo, sostituendo quello corrente, e il vecchio nodo viene successivamente distrutto utilizzando la callback RCU”, sottolinea Minnella.
Race condition
Inoltre “è possibile notare che la vulnerabilità deriva da una condizione detta di race condition.
Mentre la callback RCU per liberare il vecchio nodo è programmata per essere eseguita dopo tutte le sezioni critiche RCU preesistenti, l’accesso ai VMA richiede solo il mantenimento del blocco di lettura MM e non entra nella sezione critica RCU. Di conseguenza, risulta possibile invocare il callback RCU, liberare il vecchio nodo mentre i puntatori al vecchio nodo sono ancora memorizzati e utilizzabili altrove”, evidenzia Minnella: “Ciò si traduce in una vulnerabilità use-after-free, in cui i successivi tentativi di accesso al vecchio nodo possono portare a comportamenti non definiti o a problemi di sicurezza”.
Come mitigare il rischio
La patch è già disponibile ed è urgente scaricarla ed installarla. “La correzione assicura il corretto lock durante l’espansione dello stack. Al momento la patch è disponibile per le sole versioni stabili del kernel (6.1.37, 6.3.11, 6.4.1). Per maggiori dettagli si rimanda al sito di ogni distribuzione”, avvisa Minnella
“Ma il problema è che non tutte le principali distribuzioni Linux hanno adottato cambiamenti in grado di mitigare il problema”, conclude Paganini. Infatti, per esempio, Ubuntu 22.04.2 LTS (Jammy Jellyfish), il cui supporto standard termina nell’aprile 2027, contiene la versione 5.19 del kernel Linux. D’altra parte, Debian 12 (Bookworm) ha il kernel Linux 6.1.
Un elenco completo delle distribuzioni Linux che utilizzano il kernel versione 6.1 o superiore è disponibile su DistroWatch. Gli utenti dovrebbero effettuare il controllo della versione del kernel su cui gira la propria distribuzione Linux, per selezionarne una non affetta da StackRot. Oppure una versione aggiornata che contenga la patch.
Serve un approccio Zero Trust, per integrare la sicurezza in tutta la propria infrastruttura, aggiornando regolarmente, installando le patch scaricate, monitorando con cura il traffico di rete per identificare eventuali comportamenti anomali.
Ruihan Li osserva che l’exploit di StackRot è impegnativo. CVE-2023-3269 potrebbe essere il primo esempio di vulnerabilità use-after-free-by-RCU (UAFBR) teoricamente sfruttabile. Tuttavia, il ricercatore ha deciso di divulgare i dettagli tecnici completi su StackRot e un exploit proof-of-concept (PoC) entro la fine di luglio. Il kernel Linux 6.1 ha ricevuto il semaforo verde come versione di supporto a lungo termine (LTS) da febbraio.
“Si raccomanda vivamente di applicare la patch tempestivamente, poiché sappiamo che i dettagli dell’exploit per sfruttare la vulnerabilità saranno pubblicati entro la fine di luglio”, conclude Minnella. Infatti “ciò significa che da quella data numerosi attori malevoli potrebbero usare lo stesso exploit, o modificarlo per crearne uno nuovo, ed usarlo in attacchi”, mette in guardia Paganini.
