Ilang araw na ang nakakalipas inilabas ang balita ang mga detalye ay inihayag isang kahinaan natagpuan iyon sa pagpapatupad ng mekanismo limitasyon ng mapagkukunan cgroup v1 sa Linux kernel na naka-catalog na sa ilalim ng CVE-2022-0492.
Ang kahinaang ito ay natagpuan se ay maaaring gamitin upang lumabas sa mga nakahiwalay na lalagyan at ito ay detalyado na ang problema ay naroroon mula noong Linux kernel 2.6.24.
Sa blog post ay nabanggit na ang kahinaan ay dahil sa isang lohikal na error sa release_agent file handler, kaya't hindi isinagawa ang wastong pagsusuri nang ang driver ay pinatakbo nang may ganap na mga pahintulot.
Ang file release_agent ay ginagamit upang tukuyin ang programa na ang kernel executes kapag ang isang proseso ay nagtatapos sa isang cgroup. Ang program na ito ay tumatakbo bilang ugat na may lahat ng "kakayahang" sa root namespace. Ang administrator lang ang dapat magkaroon ng access sa release_agent configuration, ngunit sa katotohanan, ang mga pagsusuri ay limitado sa pagbibigay ng access sa root user, na hindi humadlang sa pagbabago ng configuration mula sa container o ng non-administrative root user (CAP_SYS_ADMIN ) .
Dati, ang feature na ito ay hindi sana maisip bilang isang kahinaan, ngunit nagbago ang sitwasyon sa pagdating ng mga namespace ng user identifier (mga namespace ng user), na nagbibigay-daan sa iyong lumikha ng hiwalay na mga root user sa mga container na hindi nagsasapawan sa root user ng pangunahing environment.
Dahil dito, para sa isang pag-atake, ito ay sapat sa isang lalagyan na may sariling root user sa isang hiwalay na espasyo ng user id upang isaksak ang iyong release_agent handler, na, kapag nakumpleto na ang proseso, ay tatakbo kasama ang lahat ng mga pribilehiyo ng parent environment.
Bilang default, ang cgroupfs ay naka-mount sa isang read-only na container, ngunit walang problema sa muling pag-mount ng mga pseudofs na ito sa write mode na may mga karapatan sa CAP_SYS_ADMIN o sa pamamagitan ng paggawa ng nested container na may hiwalay na user namespace gamit ang system call para sa paghinto ng pagbabahagi, kung saan ang mga karapatan ng CAP_SYS_ADMIN ay magagamit sa ginawang lalagyan.
Ang pag-atake ay maaaring gawin sa pamamagitan ng pagkakaroon ng mga pribilehiyo sa ugat sa isang nakahiwalay na lalagyan o sa pamamagitan ng pagpapatakbo ng lalagyan nang walang no_new_privs flag, na nagbabawal sa pagkakaroon ng karagdagang mga pribilehiyo.
Dapat ay may suporta ang system para sa mga namespace na pinagana user (naka-enable bilang default sa Ubuntu at Fedora, ngunit hindi naka-enable sa Debian at RHEL) at may access sa root v1 cgroup (halimbawa, ang Docker ay nagpapatakbo ng mga container sa RDMA root cgroup). Posible rin ang pag-atake na may mga pribilehiyong CAP_SYS_ADMIN, kung saan hindi kinakailangan ang suporta para sa mga namespace ng user at access sa root hierarchy ng cgroup v1.
Bilang karagdagan sa paglabas sa nakahiwalay na lalagyan, pinapayagan din ng kahinaan ang mga prosesong sinimulan ng root user na walang "capability" o sinumang user na may mga karapatan sa CAP_DAC_OVERRIDE (ang pag-atake ay nangangailangan ng access sa /sys/fs/cgroup/*/release_agent file na pag-aari ni root) upang makakuha ng access sa lahat ng "kakayahan" ng system.
Bukod sa mga lalagyan, ang kahinaan ay maaari ring payagan ang mga proseso ng root host na walang mga kakayahan, o mga prosesong hindi root host na may kakayahan na CAP_DAC_OVERRIDE, na palakihin ang mga pribilehiyo sa buong kakayahan. Maaaring payagan nito ang mga umaatake na lampasan ang isang hardening measure na ginagamit ng ilang partikular na serbisyo, na nag-aalis ng mga kakayahan sa pagtatangkang limitahan ang epekto kung may naganap na kompromiso.
Inirerekomenda ng Unit 42 ang mga user na mag-upgrade sa isang nakapirming bersyon ng kernel. Para sa mga tumatakbong container, paganahin ang Seccomp at tiyaking naka-enable ang AppArmor o SELinux. Maaaring sumangguni ang mga user ng Prisma Cloud sa seksyong "Mga Proteksyon ng Prisma Cloud" upang makita ang mga pagpapagaan na ibinigay ng Prisma Cloud.
Tandaan na ang kahinaan ay hindi maaaring samantalahin kapag gumagamit ng Seccomp, AppArmor o SELinux na mekanismo ng proteksyon para sa karagdagang pag-iisa ng container, dahil hinaharangan ng Seccomp ang unshare() system call at hindi pinapayagan ng AppArmor at SELinux na ma-mount ang cgroupfs sa write mode.
Sa wakas, ito ay nagkakahalaga ng pagbanggit na ito ay naayos sa mga bersyon ng kernel 5.16.12, 5.15.26, 5.10.97, 5.4.177, 4.19.229, 4.14.266 at 4.9.301. Maaari mong sundin ang paglabas ng mga update sa package sa mga pamamahagi sa mga page na ito: Debian, SUSE, Ubuntu, RHEL, Fedora, Gentoo, Arch Linux.
Sa wakas kung interesado kang malaman ang tungkol dito, maaari mong suriin ang mga detalye sa sumusunod na link.