Pochi giorni fa la notizia è stata diffusa i dettagli sono stati rivelati una vulnerabilità che è stato trovato nell'attuazione del meccanismo limitazione delle risorse cgroup v1 nel kernel Linux che è già catalogato sotto CVE-2022-0492.
Questa vulnerabilità trovata se può essere utilizzato per uscire da container isolati ed è dettagliato che il problema è presente dal kernel Linux 2.6.24.
Nel post del blog è menzionato che la vulnerabilità è dovuta a un errore logico nel gestore del file release_agent, quindi i controlli appropriati non sono stati eseguiti quando il driver è stato eseguito con autorizzazioni complete.
il file release_agent viene utilizzato per definire il programma che esegue il kernel quando un processo termina in un cgroup. Questo programma viene eseguito come root con tutte le "capacità" nello spazio dei nomi di root. Solo l'amministratore doveva avere accesso alla configurazione release_agent, ma in realtà i controlli si limitavano a concedere l'accesso all'utente root, il che non precludeva la modifica della configurazione dal container o da parte dell'utente root non amministrativo (CAP_SYS_ADMIN ) .
in precedenza, questa caratteristica non sarebbe stata percepita come una vulnerabilità, ma la situazione è cambiata con l'avvento degli spazi dei nomi degli identificatori utente (spazi dei nomi degli utenti), che consentono di creare utenti root separati in contenitori che non si sovrappongono all'utente root dell'ambiente principale.
di conseguenza, per un attacco, è sufficiente in un contenitore che abbia il proprio utente root in uno spazio ID utente separato per collegare il gestore release_agent, che, una volta completato il processo, verrà eseguito con tutti i privilegi dell'ambiente padre.
Per impostazione predefinita, cgroupfs è montato in un contenitore di sola lettura, ma non ci sono problemi a rimontare questo pseudofs in modalità di scrittura con i diritti CAP_SYS_ADMIN o creando un contenitore annidato con uno spazio dei nomi utente separato utilizzando la chiamata di sistema per interrompere la condivisione, in cui i diritti CAP_SYS_ADMIN sono disponibili per il contenitore creato.
L'attacco può essere fatto avendo i privilegi di root in un contenitore isolato o eseguendo il contenitore senza il flag no_new_privs, che impedisce di ottenere privilegi aggiuntivi.
Il sistema deve avere il supporto per gli spazi dei nomi abilitato utente (abilitato per impostazione predefinita su Ubuntu e Fedora, ma non abilitato su Debian e RHEL) e avere accesso al cgroup root v1 (ad esempio, Docker esegue i container nel cgroup root RDMA). L'attacco è possibile anche con i privilegi CAP_SYS_ADMIN, nel qual caso non è richiesto il supporto per gli spazi dei nomi utente e l'accesso alla gerarchia radice di cgroup v1.
Oltre a rompere il container isolato, la vulnerabilità consente anche processi avviati dall'utente root senza "capability" o da qualsiasi utente con diritti CAP_DAC_OVERRIDE (l'attacco richiede l'accesso al file /sys/fs/cgroup/*/release_agent di proprietà di root) per ottenere l'accesso a tutte le "capacità" del sistema.
Oltre ai container, la vulnerabilità può anche consentire ai processi host root senza funzionalità o ai processi host non root con la funzionalità CAP_DAC_OVERRIDE di elevare i privilegi a funzionalità complete. Ciò può consentire agli aggressori di aggirare una misura di rafforzamento utilizzata da determinati servizi, che rimuove le funzionalità nel tentativo di limitare l'impatto in caso di compromissione.
L'unità 42 consiglia agli utenti di eseguire l'aggiornamento a una versione fissa del kernel. Per i container in esecuzione, abilita Seccomp e assicurati che AppArmor o SELinux siano abilitati. Gli utenti di Prisma Cloud possono fare riferimento alla sezione "Protezioni Prisma Cloud" per vedere le mitigazioni fornite da Prisma Cloud.
Si noti che la vulnerabilità non può essere sfruttata quando si utilizzano i meccanismi di protezione Seccomp, AppArmor o SELinux per un isolamento aggiuntivo del contenitore, poiché Seccomp blocca la chiamata di sistema unshare() e AppArmor e SELinux non consentono il montaggio di cgroupfs in modalità di scrittura.
Infine, vale la pena ricordare che è stato corretto nelle versioni del kernel 5.16.12, 5.15.26, 5.10.97, 5.4.177, 4.19.229, 4.14.266 e 4.9.301. Puoi seguire il rilascio degli aggiornamenti dei pacchetti nelle distribuzioni su queste pagine: Debian, SUSE, Ubuntu, RHEL, Fedora, Gentoo, Arch Linux.
Infine se sei interessato a saperne di più, puoi controllare i dettagli nel file seguente link