recentemente informazioni sulla vulnerabilità divulgate (CVE-2022-29582) nell'implementazione dell'interfaccia I/O asincrona io_uring, inclusa nel kernel Linux dalla versione 5.1, che consente a un utente non privilegiato di diventare root sul sistema, anche durante l'esecuzione di un exploit del contenitore.
Vale la pena menzionarlo tale vulnerabilità è stata segnalata poco più di 3 mesi fa (approssimativamente all'inizio di maggio di quest'anno), ma le informazioni complete e la divulgazione sono state rilasciate solo di recente.
Per quanto riguarda la vulnerabilità, si dice che questo si verifica quando si accede a un blocco di memoria già liberato, si manifesta nei kernel Linux a partire dal ramo 5.10.
Informazioni sulla vulnerabilità CVE-2022-29582
Questa vulnerabilità consente l'accesso alla memoria liberata come risultato di una race condition durante la gestione dei timeout nella funzione io_flush_timeouts(), chee rimuove la voce di timeout dall'elenco e lo annulla, senza verificare in quel momento la creazione e l'eliminazione del timeout.
Una descrizione generale aggiornata di io_uring è già stata fornita da altri. Lo spiegano mille volte meglio di noi, quindi tratteremo il sottosistema in modo più estensivo (vedi questo articolo sulla sicurezza di Grapl e questo articolo sulla sicurezza di Flatt per un'ottima introduzione).
Cosa è più importante, il campo codice operativo determina quale tipo di operazione eseguire. Per ogni "opcode" che lo richiede, il campo fd specifica il descrittore di file su cui eseguire l'I/O richiesto. Quasi tutte le normali chiamate di sistema I/O (read, sendto, ecc.) hanno un codice operativo asincrono equivalente. Ogni campo può assumere ruoli diversi a seconda dell'operazione.
Una volta recuperato dall'SQ, un SQE viene convertito in una rappresentazione interna descritta da struct io_kiocb( call back input/output del kernel). Questi oggetti sono comunemente noti come richieste.
struct io_kiocb è usato come equivalente dell'SQE "ready-for-launch" su cui si basa, per cui qualsiasi descrittore di file viene risolto per struct file*s, le credenziali dell'utente sono allegate, la personalità (in cui verranno eseguiti i core), ecc. .
Al termine dell'operazione richiesta, viene scritta nella coda di completamento (CQ) una voce che corrisponde all'SQE. Tale voce è denominata voce di coda di completamento (CQE) e contiene campi come un codice di errore e un valore di risultato. L'applicazione dello spazio utente può eseguire il polling del CQ per le nuove voci per determinare se gli SQE inviati hanno terminato l'elaborazione e quale è stato il loro risultato.
Si dice che ci sono alcuni scenari in cui è facile sostituire un oggetto sul progresso. Ma ci sono due limiti:
- LT' deve essere assegnato e inizializzato in una finestra di gara. Cioè, dopo che il LT è stato rilasciato ma prima di raggiungere un punto nel LT a cui non si accede più.
- LT' può essere solo un altro oggetto struct io_kiocb. A causa dell'isolamento dell'heap, in cui gli oggetti nell'heap sono separati in base al tipo, è troppo difficile riassegnarli come un diverso tipo di oggetto all'interno della finestra della gara.
I ricercatori hanno preparato un exploit funzionale che non richiede l'inclusione di spazi dei nomi identificativi utente (spazi dei nomi utente) per il suo funzionamento e può fornire l'accesso root all'host quando un utente senza privilegi avvia l'exploit in un contenitore isolato.
Il nostro exploit prende di mira la versione del kernel 5.10.90, la versione che Google era in esecuzione in remoto in quel momento. Abbiamo dovuto adattare il nostro exploit alle specifiche specifiche del server (4 core Skylake Xeon @ 2.80Ghz, 16GiB RAM), ma con alcune modifiche, qualsiasi macchina che esegue un kernel vulnerabile dovrebbe essere sfruttabile.
L'exploit funziona anche nell'ambiente nsjail isolato su distribuzione Google COS (Container Optimized OS) basato su Chromium OS e utilizzato su Google Cloud Platform su macchine virtuali Compute Engine. L'exploit è progettato per funzionare con i rami del kernel da 5.10 a 5.12. Infine, vale la pena menzionarlo il problema risolto ad aprile negli aggiornamenti 5.10.111, 5.15.34 e 5.17.3.
Infine, se sei interessato a saperne di più sulla vulnerabilità, puoi consultare la pubblicazione realizzata nel seguente link