Sono state identificate due nuove vulnerabilità nel sottosistema eBPF, che consente di eseguire gestori all'interno del kernel Linux in una speciale macchina virtuale con JIT. Entrambe le vulnerabilità consentono di eseguire il codice con diritti del kernel, al di fuori di una macchina virtuale eBPF isolata. Le informazioni sui problemi sono state pubblicate dal team Zero Day Initiative, che gestisce il concorso Pwn2Own, durante il quale quest'anno sono stati dimostrati tre attacchi su Ubuntu Linux che utilizzavano vulnerabilità precedentemente sconosciute (non viene riportato se le vulnerabilità in eBPF siano correlate a questi attacchi) .
- CVE-2021-3490 - La vulnerabilità è causata dalla mancanza del controllo fuori dai limiti a 32 bit durante l'esecuzione di operazioni AND, OR e XOR bit a bit in eBPF ALU32. Un utente malintenzionato può sfruttare questo errore per leggere e scrivere dati al di fuori dei limiti del buffer allocato. Il problema con le operazioni XOR appare a partire dalla versione del kernel 5.7-rc1, mentre AND e OR a partire dalla versione 5.10-rc1.
- CVE-2021-3489 - La vulnerabilità è causata da un errore nell'implementazione del ring buffer ed è dovuta al fatto che la funzione bpf_ringbuf_reserve non ha verificato la possibilità che la dimensione della regione di memoria allocata potesse essere inferiore alla dimensione effettiva del ringbuff. Il problema si presenta a partire dalla versione 5.8-rc1.
Lo stato delle patch delle vulnerabilità nelle distribuzioni può essere monitorato su queste pagine: Ubuntu, Debian, RHEL, Fedora, SUSE, Arch). Le correzioni sono disponibili anche come patch (CVE-2021-3489, CVE-2021-3490). La possibilità di sfruttare il problema dipende dal fatto che la chiamata di sistema eBPF sia accessibile all'utente. Ad esempio, nella configurazione predefinita in RHEL, lo sfruttamento della vulnerabilità richiede che l'utente disponga dei diritti CAP_SYS_ADMIN.
Separatamente, possiamo notare un'altra vulnerabilità nel kernel Linux: CVE-2021-32606, che consente a un utente locale di aumentare i propri privilegi al livello di root. Il problema è evidente a partire dal kernel Linux 5.11 ed è causato da una race condition nell'implementazione del protocollo CAN ISOTP, che rende possibile modificare i parametri di associazione del socket a causa della mancata impostazione dei lock adeguati nella funzione isotp_setsockopt() durante l'elaborazione del flag CAN_ISOTP_SF_BROADCAST.
Dopo la chiusura del socket ISOTP rimane attivo il legame con il socket destinatario, che potrà continuare ad utilizzare le strutture associate al socket dopo che sarà stata liberata la memoria ad esse associata (use-after-free a causa della chiamata ad una struttura isotp_sock che è già stato liberato quando viene chiamato isotp_rcv()). Attraverso la manipolazione dei dati, puoi sovrascrivere il puntatore alla funzione sk_error_report() ed eseguire il codice a livello di kernel.
Fonte: opennet.ru