Gibutyag na ang mga detalye sa usa ka kahuyangan (CVE-2022-0492) sa cgroups v1 resource throttling mechanism sa Linux kernel. Kini nga kahuyangan mahimong pahimuslan aron makaikyas sa mga isolated container. Ang isyu makita sugod sa Linux kernel 2.6.24 ug naayo sa mga kernel releases nga 5.16.12, 5.15.26, 5.10.97, 5.4.177, 4.19.229, 4.14.266, ug 4.9.301. Mahimo nimong masubay ang mga package update releases para sa piho nga mga distribusyon sa mosunod nga mga panid: Debian, SUSE, Ubuntu, RHEL, Fedora, Gentoo, ug Arch Linux.
Ang kahuyangan gipahinabo sa usa ka lohikal nga sayop sa release_agent file handler, nga nakapugong sa hustong mga pagsusi kung gipadagan ang handler nga adunay bug-os nga mga pribilehiyo. Ang release_agent file gigamit aron ipasabut ang usa ka programa nga gipatuman sa kernel kung ang usa ka proseso sa usa ka cgroup matapos. Kini nga programa nagdagan nga adunay mga pribilehiyo sa root ug tanan nga mga kapabilidad sa root namespace. Ang pag-access sa release_agent configuration gituyo nga limitahan sa administrador, apan sa tinuud, ang mga pagsusi limitado sa paghatag og access sa root user, nga wala makapugong sa pag-usab sa configuration gikan sa sulod sa container o sa usa ka root user nga walay mga pribilehiyo sa administratibo (CAP_SYS_ADMIN).
Kaniadto, kini nga bahin dili unta isipon nga usa ka kahuyangan, apan ang sitwasyon nausab sa pag-abot sa mga user namespace, nga nagtugot sa paghimo og managlahing root user sa mga container nga dili mo-overlap sa root user sa main environment. Busa, aron makahimo og pag-atake, ang usa ka container nga adunay kaugalingong root user sa usa ka managlahing user namespace kinahanglan lang nga maglakip sa kaugalingong release_agent handler. Human matapos ang proseso, ang handler mo-execute nga adunay bug-os nga mga pribilehiyo sa main environment.
Sa default, ang cgroupfs gi-mount sa usa ka container sa read-only mode, apan walay problema sa pag-remount niini nga pseudo-fs sa write mode kung ikaw adunay CAP_SYS_ADMIN rights o pinaagi sa paghimo og nested container nga adunay lahi nga user namespace gamit ang unshare system call, diin ang CAP_SYS_ADMIN rights anaa para sa gihimo nga container.
Ang pag-atake mahimong himuon gamit ang mga pribilehiyo sa root sa usa ka isolated container o kung nagpadagan og container nga walay no_new_privs flag, nga makapugong sa dugang nga mga pribilehiyo. Kinahanglan nga ang sistema adunay mga user namespace nga naka-enable (naka-enable pinaagi sa default sa Ubuntu ug Fedora, apan dili naka-enable sa Debian ug RHEL) ug access sa root cgroup v1 (pananglitan, ang Docker nagpadagan og mga container sa root RDMA cgroup). Posible usab ang pag-atake gamit ang mga pribilehiyo sa CAP_SYS_ADMIN, diin ang mga user namespace ug access sa root cgroup v1 hierarchy dili kinahanglan.
Gawas sa pag-ikyas gikan sa usa ka nahimulag nga container, ang kahuyangan nagtugot usab sa mga proseso nga gilunsad sa usa ka root user nga walay mga kapabilidad, o sa bisan kinsang user nga adunay mga pribilehiyo sa CAP_DAC_OVERRIDE (ang pag-atake nanginahanglan og access sa /sys/fs/cgroup/*/release_agent file, nga gipanag-iya sa root), aron makakuha og access sa tanang kapabilidad sa sistema.
Namatikdan nga ang kahuyangan dili mapahimuslan kung gamiton ang mga mekanismo sa proteksyon sa Seccomp, AppArmor, o SELinux alang sa dugang nga pag-isolate sa container, tungod kay gibabagan sa Seccomp ang access sa unshare() system call, ug ang AppArmor ug SELinux dili motugot sa pag-mount sa cgroupfs sa write mode.
Source: opennet.ru
