{"id":103483,"date":"2022-03-06T15:36:45","date_gmt":"2022-03-06T13:36:47","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/uyazvimost-v-cgroups-v1-pozvolyayushhaya-vyjti-iz-izolirovannogo-kontejnera"},"modified":"2022-03-06T15:36:45","modified_gmt":"2022-03-06T13:36:47","slug":"uyazvimost-v-cgroups-v1-pozvolyayushhaya-vyjti-iz-izolirovannogo-kontejnera","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/news\/uyazvimost-v-cgroups-v1-pozvolyayushhaya-vyjti-iz-izolirovannogo-kontejnera","title":{"rendered":"Vulnerabilit\u00e0 in cgroups v1 che consente di uscire da un container isolato","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Sono stati rivelati i dettagli di una vulnerabilit\u00e0 (CVE-2022-0492) nell'implementazione del meccanismo di limitazione delle risorse cgroups v1 nel kernel Linux, che pu\u00f2 essere utilizzata per uscire da container isolati. Il problema si manifesta a partire dal kernel Linux 2.6.24 ed \u00e8 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. <\/p>\n
La vulnerabilit\u00e0 \u00e8 causata da un errore logico nel gestore di file release_agent, che non eseguiva le necessarie verifiche durante l'avvio del gestore con l'intero set di privilegi. Il file release_agent viene utilizzato per determinare il programma eseguito dal kernel al termine di un processo nel cgroup. Questo programma viene avviato con i diritti di root e con tutte le 'capabilities' nello spazio dei nomi root. Si presumeva che solo l'amministratore avesse accesso alla configurazione di release_agent, ma in realt\u00e0 le verifiche si limitavano a fornire l'accesso all'utente root, il che non escludeva la modifica della configurazione da parte di un container o da un utente root senza diritti di amministratore (CAP_SYS_ADMIN). <\/p>\n
In passato, una tale caratteristica non sarebbe stata considerata una vulnerabilit\u00e0, ma la situazione \u00e8 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 \u00e8 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\u00e0 eseguito dopo la fine del processo con pieni privilegi dell'ambiente principale. <\/p>\n
Per impostazione predefinita, cgroupfs \u00e8 montato nel container in modalit\u00e0 di sola lettura, ma non ci sono problemi a rimontare questo pseudo-filesystem in modalit\u00e0 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.
<\/center> <\/p>\n
Un attacco pu\u00f2 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 \u00e8 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. <\/p>\n
Oltre all'uscita da un container isolato, la vulnerabilit\u00e0 consente anche ai processi avviati dall'utente root senza 'capabilities' o a qualsiasi utente con diritti CAP_DAC_OVERRIDE (per attaccare \u00e8 necessario avere accesso al file \/sys\/fs\/cgroup\/*\/release_agent, di propriet\u00e0 di root), di accedere a tutte le 'capabilities' di sistema. <\/p>\n
![\"Vulnerabilit\u00e0](\"\/wp-content\/uploads\/2022\/03\/710b37582c444cc4be7d6ae4695c8afe.jpg\")
<\/center> <\/p>\n