Sono emersi dettagli su una vulnerabilità (CVE-2022-0492) nell'implementazione del meccanismo di limitazione delle risorse cgroups v1 nel kernel Linux, che può essere sfruttata per uscire da contenitori isolati. Il problema si manifesta a partire dal kernel Linux 2.6.24 ed è 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. È possibile tenere traccia della pubblicazione degli aggiornamenti dei pacchetti nelle distribuzioni sulle seguenti pagine: Debian, SUSE, Ubuntu, RHEL, Fedora, Gentoo, Arch Linux.
La vulnerabilità è causata da un errore logico nel gestore di file release_agent, che non effettuava le dovute verifiche durante l'esecuzione del gestore con pieni privilegi. Il file release_agent è utilizzato per determinare il programma eseguito dal kernel al termine di un processo in cgroup. Questo programma viene avviato con i diritti root e con tutte le "capabilities" nello spazio dei nomi radice. Si presumeva che solo l'amministratore avesse accesso alla configurazione di release_agent, ma in realtà le verifiche erano limitate all'accesso fornito all'utente root, il che non escludeva la modifica della configurazione dal contenitore o da un utente root senza privilegi di amministratore (CAP_SYS_ADMIN).
In passato, tale caratteristica non sarebbe stata vista come una vulnerabilità, ma la situazione è cambiata con l'introduzione degli spazi dei nomi degli identificatori degli utenti (user namespaces), che permettono di creare all'interno dei container utenti root separati, non in conflitto con l'utente root dell'ambiente principale. Di conseguenza, per attaccare è sufficiente connettere il proprio handler release_agent in un container che ha il proprio utente root in uno spazio di identificazione degli utenti separato, il quale verrà eseguito con pieni privilegi dell'ambiente principale dopo il termine del processo.
Di default, cgroupfs è montato nel container in modalità di sola lettura, ma non ci sono problemi a rimontare questo pseudo filesystem in modalità di scrittura se si hanno i diritti CAP_SYS_ADMIN o creando tramite la chiamata di sistema un container annidato con uno spazio dei nomi degli utenti separato, in cui per il container creato sono disponibili i diritti CAP_SYS_ADMIN.
Un attacco può essere effettuato con i privilegi di root in un contenitore isolato o avviando un contenitore senza il flag no_new_privs, che vieta l'acquisizione di privilegi aggiuntivi. La sistema deve avere attivato il supporto per i namespaces utente (che è attivato di default in Ubuntu e Fedora, ma non in Debian e RHEL) e deve avere accesso al gruppo cgroup v1 root (ad esempio, Docker avvia i contenitori nel gruppo RDMA root cgroup). L'attacco è possibile anche con i privilegi CAP_SYS_ADMIN, in questo caso non è richiesta la supporto per i namespaces utente e l'accesso alla gerarchia cgroup v1 root.
Oltre all'uscita dal contenitore isolato, la vulnerabilità consente anche ai processi eseguiti dall'utente root senza "capabilities" o da qualsiasi utente con diritti CAP_DAC_OVERRIDE (per l'attacco è necessaria l'accesso al file /sys/fs/cgroup/*/release_agent, che appartiene a root) di accedere a tutte le "capabilities" di sistema.
Si segnala che la vulnerabilità non può essere sfruttata quando sono attivi meccanismi di protezione come Seccomp, AppArmor o SELinux per un'ulteriore isolamento dei contenitori, poiché Seccomp blocca l'accesso alla chiamata di sistema unshare(), e AppArmor e SELinux non consentono di montare cgroupfs in modalità scrittura.
Fonte: opennet.ru
