Flipping pages: il nuovo bug del Kernel Linux mette a rischio la sicurezza dei sistemi

Sergio Corpettini : 4 Aprile 2024 15:25

Su X, Lau (@notselwyn) (https://twitter.com/notselwyn/) ha rilasciato il 26 marzo un blogpost su https://pwning.tech/nftables/ descrivendo un elaborato attacco al kernel Linux che permette privilege escalation sfruttando una vulnerabilità in nf_tables. Il POC, pubblicato su Github, partendo da una doppia free() porta il kernel a eseguire codice arbitrario con privilegi root.

Di cosa stiamo parlando

Un attacco di privilege escalation permette, partendo da privilegi utente, di ottenere privilegi più alti, generalmente quelli di amministratore, o root.

Il Kernel é il primo strato di software che “abbraccia” e protegge l’hardware. Nei moderni sistemi operativi, uno dei suoi compiti più importanti è mantenere i processi in isole separate e protette. In alcuni casi un processo ha bisogno di accedere a risorse “privilegiate” e in quel caso può chiedere gentilmente al kernel di provvedere lui a eseguire la richiesta con i suoi superpoteri e rispondere in seguito al processo chiamante con il risultato, senza bisogno di mandare in esecuzione l’intero processo con privilegi elevati.

Un Kernel Exploit attacca direttamente questa catena di comunicazione fra userland e kernel riuscendo a far eseguire al kernel qualcosa che non dovrebbe, risultando nell’esecuzione di codice proveniente da userland con i privilegi del kernel. Ma vediamo qualche dettaglio in più.

Confusione

Il kernel linux si occupa anche della sicurezza di rete, “siede” direttamente sulle schede di rete, analizza il traffico e applica le regole del firewall interno. Le regole del firewall vengono definite tramite Netfilter.

@notselwyn inizia il dialogo col kernel impostando una nuova regola Netfilter forgiata ad hoc da userland che forza il kernel a liberare un’area di memoria due volte di seguito (la doppia free() citata all’inzio). Poi inizia a saturare il kernel con pacchetti forgiati appositamente per impattare quella regola.

A questo punto il kernel è molto confuso: forzandolo a liberare un’area di memoria due volte di seguito, il processo in userland sarà in grado di accedere a quella memoria utilizzando un puntatore che in teoria non avrebbe dovuto più essere accessibile. Questo dà accesso al processo userland ad aree di memoria privilegiate.

Esistono meccanismi nel Kernel che dovrebbero proteggere da questo genere di attacchi, ma utilizzando tecniche che vanno oltre le finalità di questo articolo (vi rimando all’articolo del ricercatore che ha scoperto questo bug, https://pwning.tech/nftables/ per l’approfondimento) è possibile evadere i controlli di prevenzione e arrivare a “forzare la mano” al kernel per fargli eseguire codice arbitrario con privilegi elevati. Codice arbitrario nel kernel significa pieno accesso a tutto: Bingo! Sei amministratore.

Impatto

La vulnerabilità use-after-free nel componente Netfilter del kernel Linux è stata catalogata come CVE-2024-1086. La CVE impatta la maggior parte dei kernel linux “vanilla” versione 5.15.y 6.1.y e 6.6.y.

Un bugfix per questa vulnerabilità è stato incluso nelle branch stable del kernel a partire da Febbraio 2024. L’impatto è ALTO (CVSSv3 7.8) poiché si tratta di un attacco diretto al Kernel e copre una configurazione “vanilla” che molte distribuzioni usano. Nell’ambito dello sviluppo del kernel Linux, il kernel “vanilla” è il kernel ufficialmente distribuito da Linus Torvalds e dai progettisti Linux, senza alcuna patch aggiuntiva.

Conclusioni: cosa fare

Aggiornare con regolarità il kernel all’ultima versione stabile su tutte le vostre macchine Linux. Gli aggiornamenti kernel specialmente nelle versioni LTE sono critici e vanno trattati con la massima urgenza. La massima “se funziona, non si tocca” non si applica a questo genere di aggiornamenti: una politica dei backup dei sistemi è indispensabile, come testare anche prima di mandare in produzione modifiche, ma mantenere i vostri sistemi, anche casalinghi, con una postura di sicurezza accettabile è imprescindibile.

In aggiunta, un’altra considerazione, forse un consiglio “old school” se vogliamo, potrebbe essere quella di cercare di mantenere il kernel in uso il più “minimale” possibile: ricompilarlo per la macchina su cui gira con i soli moduli di cui si ha veramente bisogno; ciò è qualcosa che potrebbe essere di difficile attuazione, specialmente in ambienti in cui ci si trova a dover gestire molti sistemi eterogenei.