CVE-2022-1015 & CVE-2022-1026

Questo README.md è una traduzione del blog di David. David ha trovato i CVE 1015 e 1016 nel kernel Linux. Puoi visitare la sua pagina web per leggere il documento originale.

Ecco i suoi profili social:

• Twitter
• Github

Un'analisi delle due nuove vulnerabilità Linux in nf_tables

Pubblicato il 2 aprile 2022.

• CVE-2022-1015 consente di effettuare un accesso out-of-bounds (fuori dai limiti) causato da scarse validazioni degli argomenti di input; può portare all'esecuzione di codice in remoto e all'escalation dei privilegi locali.
• CVE-2022-1016 è correlato a una scarsa inizializzazione delle variabili allocate nello stack, che può essere usato per far trapelare un'ampia varietà di dati del kernel verso lo spazio utente (userspace).

Questi problemi dovrebbero essere sfruttabili nelle configurazioni predefinite della versione più recente di Ubuntu e di RHEL. Ho scritto la mia proof of concept (PoC) per il CVE-2022-1015 prendendo di mira la versione del kernel 5.16-rc3 di Arch Linux.

Questo documento è rivolto alle persone che abbiano una conoscenza di base del kernel Linux in termini di funzionalità e sicurezza. Ho cercato di rendere questo documento accessibile anche a chi non ha familiarità con lo stack di rete, così da renderlo fruibile a tutti.

Ecco una guida alla lettura:

• Se sei qui semplicemente per leggere della vulnerabilità, inizia dalla Sezione 4
• Se vuoi anche un po' di contesto sul sottosistema del kernel, inizia dalla Sezione 2
• Se sei interessato a un contesto aggiuntivo, leggi l'intero documento

1. Contesto

A metà febbraio, il programma di sicurezza di Google ha annunciato che avrebbe continuato il suo programma di ricompense kCTF, offrendo ricompense che vanno da $31.337 fino a 91.337 dollari per un exploit nel kernel Linux in grado di elevare i privilegi all'utente root da processi senza privilegi in una sandbox nsjail.

Essendo uno studente squattrinato, ovviamente questo ha catturato la mia attenzione. Era la mia prima volta alla ricerca di una vulnerabilità del "mondo reale", ma nelle mie avventure giocando a CTF con la mia squadra, ho acquisito familiarità con il kernel Linux in termini di sicurezza. Dopo ore e ore con pochissimo o nessun progresso (ma con una maggiore conoscenza di Linux), sono riuscito a trovare alcune vulnerabilità nel modulo nf_tables.

Purtroppo, alla fine dei conti, mi sono reso conto che questo modulo non era presente nelle regole del kCTF di Google (quindi non ho ricevuto alcuna ricompensa per queste due vulnerabilità). Ma ovviamente le ho comunque segnalate e ho scritto un exploit LPE (Escalation dei Privilegi Locali) per il CVE-2022-1015.

1.1 Identificare l'obiettivo e la strategia di audit

Bene, quindi hai deciso che troverai alcune vulnerabilità in Linux. E adesso? Linux è un progetto gigantesco, ed è molto facile non vedere il bosco per gli alberi (ti concentri così tanto sui dettagli da perdere di vista ciò che è davvero importante, non hai una visione generale della situazione). Per peggiorare le cose, molte parti non sono documentate e devi leggere un sacco di codice per capire cosa sta succedendo.

Ho iniziato cercando di avere una prospettiva dettagliata del modello di sicurezza di Linux. Trovare un bug è una cosa; ma trovare un buon bug è un'altra cosa molto diversa. Dopotutto, non tutti i bug sono creati uguali:

• Se un bug richiede privilegi root, non esiste un limite di sicurezza significativo (a meno che il kernel module signing non sia attivato)
  • Alcune cose che mi vengono in mente sono molti dei moduli dei filesystem (virtuali). Solo l'utente root iniziale può montare questi filesystem. L'eccezione ricade in vfe che specifica FS_USERNS_MOUNT, nel qual caso puoi montarli nello user namespace.
• Se non si può accedere a un bug tramite le syscall, probabilmente non sarà sfruttabile.
  • Questo si applica a molti driver hardware, poiché non hai accesso fisico alla macchina. I driver di rete di basso livello potrebbero comunque essere un buon obiettivo se puoi, p. es., inviare dati tramite bluetooth o 802.11.ac.
  • Ovviamente questo dipende dallo scenario in cui ti trovi.
• Molti bug richiedono CAP_SYS_ADMIN o CAP_NET_ADMIN.
  • Gli user namespaces (spazi dei nomi) sono attivi per impostazione predefinita, quindi questo non è un problema.
  • Altrimenti dovrai prima fare un'escalation dei privilegi al namespace (spazio dei nomi) dell'utente root all'interno di un container.
• Non tutti i moduli saranno presenti nel tuo obiettivo.
  • Linux è un pezzo di software eccezionale altamente configurabile, quindi tutte le configurazioni possono variare in una moltitudine di modi.
  • La configurazione del kernel di solito è accessibile da /proc/config.gz. I moduli possono essere caricati (=m) oppure compilati separatamente e caricati in fase di esecuzione (=y).
  • Puoi usare /proc/modules e /proc/kallsyms, ma non sono sempre affidabili, poiché i moduli possono essere caricati dinamicamente nel kernel (p. es. request_module).
  • Se non sei sicuro, scrivi un piccolo programma che provi a interagire con il modulo.

Queste restrizioni ci aiutano a capire i limiti dei sottosistemi in cui possiamo cercare vulnerabilità. Penso che sia una buona idea prenderti il tuo tempo per cercare di pianificare il tuo attacco all'obiettivo che desideri.

Ho già imparato la lezione sul punto precedente. Come ho detto, il modulo nf_tables non era caricato nell'istanza che ci ha presentato kCTF. Avrei potuto accorgermene fin dall'inizio e risparmiarmi la delusione :p. D'altra parte, probabilmente non staresti leggendo questo blog adesso se me ne fossi accorto prima; suppongo che le cose siano andate bene dopo tutto.

Una spiegazione del perché il COS, il fork Linux container-optimized di Google, non avesse nf_tables può essere trovata qui e qui.

1.2 nf_tables: perché?

Dopo aver valutato i punti sopra menzionati, ho deciso che la mia migliore strada per iniziare sarebbe probabilmente stata guardare il codice sorgente della rete. Molte delle funzionalità interessanti lì richiedono CAP_NET_ADMIN, ma come ho detto, in realtà questo non è un problema. Al contrario, sospetto che i componenti che richiedono capacità speciali siano generalmente meno sicuri, poiché gli sviluppatori del kernel possono avere un falso senso di sicurezza.

Ho anche fatto lo sforzo di scegliere il sottosistema di cui volevo saperne di più; in questo modo, anche se non trovi alcun bug, potrai comunque imparare un sacco di cose interessanti.