O vulnerabilitate în cgroups v1, care permite ieșirea dintr-un container izolat

Detalii despre vulnerabilitatea (CVE-2022-0492) din implementarea mecanismului de limitare a resurselor cgroups v1 în nucleul Linux au fost dezvăluite. Aceasta poate fi utilizată pentru a ieși din containerele izolate. Problema apare începând cu nucleul Linux 2.6.24 și a fost remediată în versiunile nucleului 5.16.12, 5.15.26, 5.10.97, 5.4.177, 4.19.229, 4.14.266 și 4.9.301. Puteți urmări publicarea actualizărilor pachetelor în distribuții pe aceste pagini: Debian, SUSE, Ubuntu, RHEL, Fedora, Gentoo, Arch Linux.

Vulnerabilitatea este cauzată de o eroare logică în handlerul fișierului release_agent, care duce la neefectuarea verificărilor corespunzătoare la executarea handlerului cu un set complet de privilegii. Fișierul release_agent este utilizat pentru a determina programul care este executat de nucleu la încheierea unui proces în cgroup. Acest program este lansat cu privilegii root și cu toate 'capabilities' în spațiul de nume rădăcină. Se presupunea că accesul la configurarea release_agent este rezervat doar administratorului, dar în realitate verificările se limitau la acordarea accesului utilizatorului root, ceea ce nu excludea modificarea configurației dintr-un container sau de către utilizatorul root fără drepturi de administrator (CAP_SYS_ADMIN).

În trecut, o asemenea particularitate nu ar fi fost percepută ca o vulnerabilitate, dar situația s-a schimbat odată cu apariția spațiilor de nume pentru identificarea utilizatorilor (user namespaces), care permit crearea de utilizatori root separați în containere, fără a se suprapune cu utilizatorul root al mediului principal. Prin urmare, pentru a lansa un atac, este suficient ca în containerul cu un utilizator root într-un spațiu de identificare utilizatori separat să se conecteze propriul handler release_agent, care va fi executat cu privilegii complete în mediul principal la finalizarea procesului.

În mod implicit, cgroupfs este montat în container în modul doar pentru citire, dar nu sunt probleme în a remonta acest pseudo-fs în modul scriere dacă există privilegii CAP_SYS_ADMIN sau prin crearea, cu apelul sistemului unshare, a unui container imersat cu un spațiu de nume utilizatori separat, în care sunt disponibile privilegii CAP_SYS_ADMIN pentru containerul creat.

O vulnerabilitate în cgroups v1, care permite ieșirea dintr-un container izolat

Atacul poate fi realizat în prezența privilegiilor root într-un container izolat sau atunci când containerul este lansat fără flagul no_new_privs, care interzice obținerea de privilegii suplimentare. Suportul pentru namespaces de utilizator trebuie să fie activat în sistem (implicit activat în Ubuntu și Fedora, dar nu activat în Debian și RHEL) și trebuie să existe acces la cgroup-ul root v1 (de exemplu, Docker lansează containere în cgroup-ul RDMA root). Atacul este, de asemenea, posibil în prezența privilegiilor CAP_SYS_ADMIN, în acest caz suportul pentru namespaces de utilizator și accesul la ierarhia cgroup-ului root v1 nu sunt necesare.

Pe lângă ieșirea din containerul izolat, vulnerabilitatea permite, de asemenea, proceselor lansate de utilizatorul root fără „capabilities” sau oricărui utilizator cu drepturile CAP_DAC_OVERRIDE (pentru atac este necesar accesul la fișierul /sys/fs/cgroup/*/release_agent, care aparține root), să obțină acces la toate „capabilities” sistemului.

Se remarcă faptul că vulnerabilitatea nu poate fi exploatată atunci când se aplică mecanismele de protecție Seccomp, AppArmor sau SELinux pentru o izolare suplimentară a containerelor, deoarece Seccomp blochează apelul de sistem unshare(), iar AppArmor și SELinux nu permit montarea cgroupfs în modul scriere.

Sursa: opennet.ro

Cumpără un hosting fiabil pentru site-uri cu protecție DDoS, servere VPS VDS 🔥 Cumpără un hosting fiabil pentru site-uri cu protecție DDoS, servere VPS VDS | ProHoster