Sono stati resi noti i dettagli di una vulnerabilità (CVE-2022-0492) nell'implementazione del meccanismo di limitazione delle risorse cgroups v1 nel kernel Linux, che può essere utilizzato per sfuggire ai contenitori isolati. Il problema è presente 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. Puoi seguire le pubblicazioni degli aggiornamenti dei pacchetti nelle distribuzioni in queste pagine: Debian, SUSE, Ubuntu, RHEL, Fedora, Gentoo, Arch Linux.
La vulnerabilità è dovuta a un errore logico nel gestore di file release_agent che non riesce a eseguire controlli adeguati quando si esegue il gestore con privilegi completi. Il file release_agent viene utilizzato per definire il programma che deve essere eseguito dal kernel quando un processo in un cgroup viene terminato. Questo programma viene eseguito come root e con tutte le "capacità" nello spazio dei nomi root. Si presumeva che solo l'amministratore avesse accesso all'impostazione release_agent, ma in realtà i controlli si limitavano a garantire l'accesso all'utente root, il che non escludeva che l'impostazione venisse modificata dal contenitore o da un utente root senza diritti di amministratore (CAP_SYS_ADMIN ).
In precedenza, tale funzionalità non sarebbe stata percepita come una vulnerabilità, ma la situazione è cambiata con l'avvento degli user namespace (spazi dei nomi utente), che consentono di creare utenti root separati in contenitori che non si sovrappongono all'utente root del sistema. ambiente principale. Di conseguenza, per un attacco, è sufficiente connettere il proprio gestore release_agent in un contenitore che ha il proprio utente root in uno spazio ID utente separato, che, dopo aver completato il processo, verrà eseguito con tutti i privilegi dell'ambiente principale.
Per impostazione predefinita, cgroupfs è montato in un contenitore in modalità di sola lettura, ma non ci sono problemi a rimontare questo pseudofs in modalità di scrittura se si dispone dei diritti CAP_SYS_ADMIN o creando un contenitore nidificato con uno spazio dei nomi utente separato utilizzando la chiamata di sistema unshare, in cui I diritti CAP_SYS_ADMIN sono disponibili per il contenitore creato.
L'attacco può essere effettuato se si dispone dei privilegi di root in un contenitore isolato o quando si esegue un contenitore senza il flag no_new_privs, che impedisce di ottenere privilegi aggiuntivi. Il sistema deve avere il supporto per gli spazi dei nomi utente abilitati (abilitati per impostazione predefinita in Ubuntu e Fedora, ma non attivati in Debian e RHEL) e avere accesso al cgroup root v1 (ad esempio, Docker esegue i contenitori nel cgroup RDMA root). L'attacco è possibile anche se si dispone dei privilegi CAP_SYS_ADMIN, nel qual caso il supporto per gli spazi dei nomi utente e l'accesso alla gerarchia root cgroup v1 non sono richiesti.
Oltre a fuoriuscire da un contenitore isolato, la vulnerabilità consente anche processi avviati da un utente root senza "capacità" o da qualsiasi utente con diritti CAP_DAC_OVERRIDE (l'attacco richiede l'accesso al file /sys/fs/cgroup/*/release_agent, che è di proprietà di root) per avere accesso a tutte le “capacità” sistemiche.
Va notato che la vulnerabilità non può essere sfruttata quando si utilizzano i meccanismi di protezione 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 il montaggio di cgroupfs in modalità di scrittura.
Fonte: opennet.ru