Sono stati rivelati i dettagli di una vulnerabilità (CVE-2022-0492) nell'implementazione del meccanismo di limitazione delle risorse cgroups v1 nel kernel Linux, che può essere utilizzata per uscire da container isolati. Il problema si manifesta a partire dal kernel Linux 2.6.24 ed è stato risolto 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. Si possono monitorare le pubblicazioni degli aggiornamenti dei pacchetti nei vari distribuzioni a queste pagine: Debian, SUSE, Ubuntu, RHEL, Fedora, Gentoo, Arch Linux.
La vulnerabilità è causata da un errore logico nel gestore dei file release_agent, che non eseguiva le necessarie verifiche all'avvio del gestore con l'intero insieme di privilegi. Il file release_agent è utilizzato per determinare il programma che il kernel esegue al termine di un processo in cgroup. Questo programma è avviato con diritti di root e con tutte le 'capabilities' nello spazio dei nomi root. Era previsto che solo l'amministratore avesse accesso alla configurazione di release_agent, ma in realtà le verifiche erano limitate alla concessione di accesso all'utente root, il che non escludeva la modifica della configurazione da un container o da un utente root senza diritti di amministratore (CAP_SYS_ADMIN).
In passato, una tale caratteristica non sarebbe stata considerata una vulnerabilità, ma la situazione è cambiata con l'introduzione degli spazi dei nomi degli identificatori degli utenti (user namespaces), che consentono di creare in container utenti root separati, non sovrapponendosi con l'utente root dell'ambiente principale. Di conseguenza, per attaccare è sufficiente nel container, che ha il proprio utente root in uno spazio dei nomi degli identificatori utenti separato, collegare il proprio gestore release_agent, che verrà eseguito dopo la fine del processo con pieni privilegi dell'ambiente principale.
Per impostazione predefinita, cgroupfs è montato nel container in modalità di sola lettura, ma non ci sono problemi a rimontare questo pseudo-filesystem in modalità scrittura con i diritti CAP_SYS_ADMIN o tramite la creazione di un container nidificato con uno spazio dei nomi utente separato usando la chiamata di sistema unshare, nel quale per il container creato sono accessibili i diritti CAP_SYS_ADMIN.
Un attacco può essere effettuato in presenza di diritti di root in un contenitore isolato o quando si avvia un contenitore senza il flag no_new_privs, che vieta l'ottenimento di privilegi aggiuntivi. La sistemazione deve avere abilitato il supporto per i namespaces utente (di default abilitato su Ubuntu e Fedora, ma non attivato su Debian e RHEL) e ci deve essere accesso al cgroup v1 root (ad esempio Docker avvia i contenitori nel cgroup RDMA root). L'attacco è possibile anche in presenza di privilegi CAP_SYS_ADMIN; in questo caso il supporto per i namespaces utente e l'accesso alla gerarchia cgroup v1 root non sono richiesti.
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'accessibilità 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 si applicano meccanismi di protezione Seccomp, AppArmor o SELinux per un'ulteriore isolamento dei contenitori, poiché Seccomp blocca l'accesso alla chiamata di sistema unshare(), mentre AppArmor e SELinux non permettono di montare cgroupfs in modalità scrittura.
Fonte: opennet.ru
