sofianehamlaoui/cve-2022-0492-checkerUno script per verificare se un ambiente container è vulnerabile a fughe di container tramite CVE-2022-0492.
Uno script per verificare se un ambiente container è vulnerabile a fughe dai container tramite CVE-2022-0492
Il 4 febbraio, Linux ha annunciato CVE-2022-0492, una nuova vulnerabilità di escalation dei privilegi nel kernel.
CVE-2022-0492 rappresenta un bug logico nei control groups (cgroups), una funzionalità Linux che è un elemento fondamentale dei container. La problematica si distingue come una delle più semplici escalation dei privilegi Linux scoperte di recente: il kernel Linux ha erroneamente esposto un'operazione privilegiata a utenti non privilegiati.
Fortunatamente, gli hardening di sicurezza predefiniti nella maggior parte degli ambienti container sono sufficienti a prevenire la fuga dal container. I container che eseguono con AppArmor o SELinux sono protetti. Detto questo, se esegui container senza gli hardening previsti dalle best practice, o con privilegi aggiuntivi, potresti essere a rischio. La sezione "Sono interessato?" elenca le configurazioni container vulnerabili e fornisce istruzioni su come testare se un ambiente container è vulnerabile.
Oltre ai container, la vulnerabilità può anche consentire a processi host root senza capabilities, o a processi host non root con la capability CAP_DAC_OVERRIDE, di escalare i privilegi e ottenere tutte le capabilities. Ciò può permettere agli attaccanti di aggirare una misura di hardening usata da alcuni servizi, che eliminano le capabilities nel tentativo di limitare l'impatto in caso di compromissione.
CVE-2022-0492 è ora la terza vulnerabilità del kernel negli ultimi mesi che consente a container malevoli di fuggire. In tutte e tre le vulnerabilità, proteggere i container con Seccomp e con AppArmor o SELinux è stato sufficiente per prevenire la fuga dal container.
Montare un cgroupfs richiede la capability CAP_SYS_ADMIN nello user namespace che ospita il cgroup namespace corrente. Per impostazione predefinita, i container girano senza CAP_SYS_ADMIM, e quindi non possono montare cgroupfs nello user namespace iniziale. Ma tramite la syscall unshare(), i container possono creare nuovi user e cgroup namespace dove possiedono la capability CAP_SYS_ADMIN e possono montare un cgroupfs.
Fig. 1 - Un container che crea un nuovo user namespace in cui avrà la capability CAP_SYS_ADMIN.
Non tutti i container possono creare un nuovo user namespace – l'host sottostante deve avere gli user namespace non privilegiati abilitati. Questo è l'impostazione predefinita nelle recenti release di Ubuntu, per esempio. Poiché Seccomp blocca la syscall unshare(), solo i container che girano senza Seccomp possono creare un nuovo user namespace. Il container mostrato nello screenshot allegato gira senza Seccomp, AppArmor o SELinux.
Fig. 2 - Il container monta il cgroup di memoria nei nuovi user e cgroup namespace.
Nello screenshot sopra, il container ha montato con successo un cgroup di memoria, ma potresti notare che il file release_agent non è incluso nella directory montata!
Come accennato in precedenza, il file release_agent è visibile solo nel root cgroup. Una limitazione del montaggio di un cgroupfs in un cgroup namespace è che monti il cgroup a cui appartieni, non il root cgroup.
Fig. 3 - Il container che monta il root RDMA cgroup nei nuovi user e cgroup namespace.
Per sfruttare il problema, dobbiamo scrivere un release agent malevolo nel file release_agent. Come visto in Fig. 3 sopra, quel file è di proprietà di root, quindi solo i processi container root possono impostare il release agent. La Fig. 4 mostra il container che imposta il release agent, mentre la Fig. 5 mostra un container non root che non riesce a farlo.
Fig. 4 - Un container root che imposta il release agent.
Fig. 5 - Un container non root non può impostare il release agent.
Il passo finale della fuga è invocare il release_agent configurato, il che non richiede alcun privilegio. Poiché questo passo è sempre realizzabile, non ha implicazioni sulla vulnerabilità di un ambiente a CVE-2022-0492, e quindi abbiamo deciso di ometterlo. Puoi comunque vedere come appare un exploit completo nello screenshot qui sotto.
Fig. 6 - Sfruttamento di CVE-2022-0492 per la fuga dal container, tramite user namespace..
Piuttosto che creare nuovi user e cgroup namespace, è possibile un exploit più semplice se al container viene concessa la capability CAP_SYS_ADMIN. Un container che gira con la capability CAP_SYS_ADMIN è autorizzato a montare cgroupfs, senza troppe domande. Come bonus, la maggior parte dei container oggi gira senza cgroup namespace, il che significa che il cgroup montato sarebbe il root cgroup e il file release_agent.
Fig. 7 - Nel cgroup namespace iniziale, il montaggio di cgroupfs monterà sempre il root cgroup, indipendentemente dal cgroup del container.
Anche con la capability CAP_SYS_ADMIN, AppArmor e SELinux impediscono comunque il montaggio, quindi i container che girano con uno dei due non possono sfruttare CVE-2022-0492. La Fig. 8 mostra un container che gira senza AppArmor e SELinux, e con la capability CAP_SYS_ADMIN, che sfrutta CVE-2022-0492 per evadere.
Fig. 8 - Sfruttamento di CVE-2022-0492 per la fuga dal container tramite la capability CAP_SYS_ADMIN.
CVE-2022-0492 rappresenta un'altra vulnerabilità Linux che può essere sfruttata per la fuga dal container. Fortunatamente, gli ambienti che seguono le best practice sono protetti da questa vulnerabilità. Gli ambienti con controlli di sicurezza permissivi che ospitano container non fidati o esposti pubblicamente sono, prevedibilmente, ad alto rischio. Come sempre, è meglio aggiornare i propri host a una versione del kernel corretta.
Raccomandiamo vivamente di eseguire i container con Seccomp e con AppArmor o SELinux abilitati, per proteggersi da questa vulnerabilità e da future vulnerabilità zero-day di Linux. Molte vulnerabilità di escalation dei privilegi nel kernel Linux possono essere sfruttate per la fuga dal container solo quando al container è consentito creare un nuovo user namespace, o in altre parole, quando il container gira senza Seccomp.
© 2022 - Non Sofiane Hamlaoui - Rendere il mondo un posto migliore 🌎
