Details fan in kwetsberens (CVE-2022-0492) yn 'e ymplemintaasje fan' e cgroups v1-boarnebeheiningsmeganisme yn 'e Linux-kernel, dy't kin wurde brûkt om isolearre konteners te ûntkommen, binne iepenbiere. It probleem is oanwêzich sûnt Linux kernel 2.6.24 en waard fêst yn kernel releases 5.16.12, 5.15.26, 5.10.97, 5.4.177, 4.19.229, 4.14.266, en 4.9.301. Jo kinne de publikaasjes fan pakketfernijings folgje yn distribúsjes op dizze siden: Debian, SUSE, Ubuntu, RHEL, Fedora, Gentoo, Arch Linux.
De kwetsberens komt troch in logyske flater yn 'e release_agent-bestânhanneler dy't net slagget om goede kontrôles út te fieren by it útfieren fan de handler mei folsleine privileezjes. It release_agent-bestân wurdt brûkt om it programma te definiearjen dat troch de kernel útfierd wurde moat as in proses yn in cgroup wurdt beëinige. Dit programma rint as root en mei alle "mooglikheden" yn 'e root nammeromte. Der waard oannommen dat allinich de behearder tagong hie ta de release_agent-ynstelling, mar yn werklikheid wiene de kontrôles beheind ta it jaan fan tagong ta de root-brûker, wat net útsloech dat de ynstelling feroare waard fan 'e kontener of troch in root-brûker sûnder administratorrjochten (CAP_SYS_ADMIN ).
Eartiids soe sa'n funksje net as in kwetsberens ûnderfûn wêze, mar de situaasje is feroare mei de komst fan brûkersnammeromten (brûkersnammeromten), wêrtroch jo aparte root-brûkers kinne oanmeitsje yn konteners dy't net oerlaapje mei de root-brûker fan 'e wichtichste omjouwing. Dêrom, foar in oanfal, is it genôch om jo release_agent-handler te ferbinen yn in kontener dy't in eigen root-brûker hat yn in aparte brûkers-ID-romte, dy't, nei it foltôgjen fan it proses, sil wurde útfierd mei folsleine privileezjes fan 'e haadomjouwing.
Standert wurdt cgroupfs yn in kontener monteard yn allinich-lêsmodus, mar d'r is gjin probleem om dizze pseudofs yn 'e skriuwmodus opnij te montearjen as jo CAP_SYS_ADMIN-rjochten hawwe of troch in nêste kontener te meitsjen mei in aparte brûkersnammeromte mei de unshare-systeemoprop, wêryn CAP_SYS_ADMIN-rjochten binne beskikber foar de oanmakke kontener.
De oanfal kin útfierd wurde as jo root-privileezjes hawwe yn in isolearre kontener of as jo in kontener útfiere sûnder de no_new_privs-flagge, dy't it krijen fan ekstra privileezjes ferbiedt. It systeem moat stipe hawwe foar brûkersnammeromten ynskeakele (standert ynskeakele yn Ubuntu en Fedora, mar net aktivearre yn Debian en RHEL) en tagong hawwe ta de root cgroup v1 (Bygelyks Docker rint konteners yn 'e root RDMA cgroup). De oanfal is ek mooglik as jo CAP_SYS_ADMIN privileezjes hawwe, yn dat gefal binne stipe foar brûkersnammeromten en tagong ta de cgroup v1 roothierarchy net fereaske.
Njonken it ûntsnappen fan in isolearre kontener, lit de kwetsberens ek prosessen lansearre wurde troch in root-brûker sûnder "mooglikheden" of elke brûker mei CAP_DAC_OVERRIDE-rjochten (de oanfal fereasket tagong ta it bestân /sys/fs/cgroup/*/release_agent, dat is eigendom fan root) om tagong te krijen ta alle systemyske "mooglikheden".
It wurdt opmurken dat de kwetsberens kin net eksploitearre by it brûken fan de Seccomp, AppArmor of SELinux beskerming meganismen foar ekstra isolaasje fan konteners, sûnt Seccomp blokkearret tagong ta de unshare () systeem oprop, en AppArmor en SELinux net tastean mounting cgroupfs yn skriuwmodus.
Boarne: opennet.ru