Sfruttamento di riferimenti nulli nel kernel Linux
È stato recentemente annunciato che i ricercatori del team Google Project Zero hanno sviluppato un metodo per sfruttare le vulnerabilità del kernel Linux causate dalla dereferenziazione del puntatore NULL.
Finora, i problemi del kernel relativi alla dereferenziazione dei puntatori NULL non hanno ricevuto la dovuta attenzione , poiché si riteneva irrealistico trasformare tali problemi in attacchi che portassero all'escalation dei privilegi o all'esecuzione di codice proprietario (la mappatura di processi non privilegiati nella regione inferiore dello spazio degli indirizzi è proibita).
In linea generale, tali errori portano alla generazione di avvisi di errore (oops warnings) da parte del kernel, dopodiché le attività problematiche vengono completate e lo stato viene ripristinato senza la necessità di arrestare il sistema.
Il nuovo metodo di attacco si basa sulla gestione degli stati "oops" , che possono portare a un aumento del valore del contatore di riferimenti (refcount), il quale a sua volta può causare un overflow del contatore e liberare la memoria associata al refcount.
In questo caso, lo sfruttamento si riduce a manipolazioni tipiche degli attacchi use-after-free (si verifica una situazione in cui il conteggio dei riferimenti dell'oggetto diventa zero, la memoria viene liberata, ma in realtà ci sono collegamenti funzionanti che puntano alla memoria liberata).
Attualmente, quando il kernel Linux rileva un dereferenziamento nullo all'interno di un contesto di processo, genera un ` oops` , che è distinto da un `kernel panic`. Un `kernel panic` si verifica quando il kernel determina che non esiste un modo sicuro per continuare l'esecuzione e pertanto deve interromperla completamente. Tuttavia, durante un `oops` il kernel non interrompe l'esecuzione; al contrario, tenta di recuperare al meglio e continua l'esecuzione.
La dereferenziazione di un puntatore NULL viene utilizzata qui come un modo per generare lo stato "oops" in modo controllato. Il problema è che sono necessarie circa 232 chiamate di stato "oops" per raggiungere un refcount overflow a 32 bit.
Da un punto di vista pratico, occorrono circa otto giorni di generazione continua di stati out-of-place (OOP) per eseguire un attacco utilizzando l'exploit proposto. In caso di successo, l'exploit consente di eseguire il codice a livello del kernel.
La dereferenziazione del puntatore NULL utilizzata nell'exploit è stata corretta in ottobre, ma poiché problemi simili non sono rari e sono stati precedentemente trattati come bug, non vulnerabilità, gli sviluppatori aggiungeranno una protezione generale al kernel Linux per prevenire attacchi che manipolano la generazione di "oops ."
Nel caso di un'attività, ciò significa scartare lo stack del kernel esistente e andare direttamente a make_task_dead che chiama do_exit. Il kernel invierà anche a dmesg un registro di "crash" e una traccia del kernel che mostra in quale stato si trovava il kernel quando si è verificato l'errore. Questa può sembrare una scelta strana quando si è chiaramente verificata la corruzione della memoria; tuttavia, l'intento è quello di rendere i bug del kernel più facili da rilevare e registrare secondo la filosofia secondo cui è molto più facile eseguire il debug di un sistema in esecuzione rispetto a uno inattivo.
In particolare , il kernel 6.2 include modifiche per limitare il numero massimo di "oops" . Dopo aver raggiunto il limite, impostato di default a 10 oops (è possibile modificarlo tramite il parametro oops_limit, se necessario), il kernel avvierà una transizione a uno stato "panic", seguito da un riavvio, che non consentirà il numero di iterazioni necessarie per azzerare il contatore dei riferimenti.
È inoltre previsto che la restrizione venga trasferita ai rami del kernel rilasciati in precedenza, ma ancora supportati, nonché ai pacchetti del kernel delle distribuzioni popolari.
Infine, se siete interessati ad approfondire l'argomento , potete trovare maggiori dettagli al seguente link.