{"id":103483,"date":"2022-03-06T15:36:45","date_gmt":"2022-03-06T13:36:47","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/uyazvimost-v-cgroups-v1-pozvolyayushhaya-vyjti-iz-izolirovannogo-kontejnera"},"modified":"2022-03-06T15:36:45","modified_gmt":"2022-03-06T13:36:47","slug":"uyazvimost-v-cgroups-v1-pozvolyayushhaya-vyjti-iz-izolirovannogo-kontejnera","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/news\/uyazvimost-v-cgroups-v1-pozvolyayushhaya-vyjti-iz-izolirovannogo-kontejnera","title":{"rendered":"Luka w cgroups v1, kt\u00f3ra umo\u017cliwia wydostanie si\u0119 z izolowanego kontenera","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Ujawniono szczeg\u00f3\u0142y podatno\u015bci (CVE-2022-0492) w implementacji mechanizmu ograniczenia zasob\u00f3w cgroups v1 w j\u0105drze Linux, kt\u00f3ra mo\u017ce by\u0107 wykorzystywana do wyj\u015bcia z izolowanych kontener\u00f3w. Problem wyst\u0119puje od j\u0105dra Linux 2.6.24 i zosta\u0142 usuni\u0119ty w wydaniach j\u0105der 5.16.12, 5.15.26, 5.10.97, 5.4.177, 4.19.229, 4.14.266 oraz 4.9.301. Mo\u017cna \u015bledzi\u0107 publikacj\u0119 aktualizacji pakiet\u00f3w w dystrybucjach na tych stronach: Debian, SUSE, Ubuntu, RHEL, Fedora, Gentoo, Arch Linux. <\/p>\n
Luka jest spowodowana b\u0142\u0119dem logicznym w obs\u0142udze plik\u00f3w release_agent, przez co nie by\u0142y przeprowadzane odpowiednie kontrole przy uruchamianiu obs\u0142ugi z pe\u0142nym zestawem uprawnie\u0144. Plik release_agent jest u\u017cywany do okre\u015blenia programu, kt\u00f3ry j\u0105dro wykonuje przy zako\u0144czeniu procesu w cgroup. Ten program uruchamiany jest z prawami root i ze wszystkimi «capabilities» w przestrzeni nazw root. Zak\u0142adano, \u017ce dost\u0119p do konfiguracji release_agent ma tylko administrator, ale w rzeczywisto\u015bci kontrole ogranicza\u0142y si\u0119 do przyznawania dost\u0119pu u\u017cytkownikowi root, co nie wyklucza\u0142o zmiany ustawienia przez kontener lub u\u017cytkownika root bez praw administratora (CAP_SYS_ADMIN). <\/p>\n
Wcze\u015bniej taka cecha nie by\u0142aby postrzegana jako podatno\u015b\u0107, ale sytuacja zmieni\u0142a si\u0119 wraz z pojawieniem si\u0119 przestrzeni nazw identyfikator\u00f3w u\u017cytkownik\u00f3w (user namespaces), kt\u00f3re umo\u017cliwiaj\u0105 tworzenie w kontenerach oddzielnych u\u017cytkownik\u00f3w roota, kt\u00f3rzy nie koliduj\u0105 z u\u017cytkownikiem root g\u0142\u00f3wnego \u015brodowiska. W zwi\u0105zku z tym do przeprowadzenia ataku wystarczy w kontenerze, maj\u0105cym swojego u\u017cytkownika roota w oddzielnej przestrzeni identyfikator\u00f3w u\u017cytkownik\u00f3w, pod\u0142\u0105czy\u0107 sw\u00f3j obs\u0142ugiwacz release_agent, kt\u00f3ry po zako\u0144czeniu procesu zostanie wykonany z pe\u0142nymi uprawnieniami g\u0142\u00f3wnego \u015brodowiska. <\/p>\n
Domy\u015blnie cgroupfs jest montowany w kontenerze w trybie tylko do odczytu, ale nie ma problem\u00f3w z ponownym montowaniem tego pseudo fs w trybie zapisu, je\u015bli s\u0105 uprawnienia CAP_SYS_ADMIN lub poprzez utworzenie za pomoc\u0105 wywo\u0142ania systemowego unshare zagnie\u017cd\u017conego kontenera z oddzieln\u0105 przestrzeni\u0105 nazw u\u017cytkownika, w kt\u00f3rej dla utworzonego kontenera dost\u0119pne s\u0105 uprawnienia CAP_SYS_ADMIN.
<\/center> <\/p>\n
Atak\u0119 mo\u017cna przeprowadzi\u0107 posiadaj\u0105c uprawnienia root w izolowanym kontenerze lub uruchamiaj\u0105c kontener bez flagi no_new_privs, kt\u00f3ra zabrania uzyskania dodatkowych przywilej\u00f3w. W systemie powinna by\u0107 w\u0142\u0105czona obs\u0142uga przestrzeni nazw u\u017cytkownik\u00f3w (domy\u015blnie w\u0142\u0105czona w Ubuntu i Fedory, ale nie aktywowana w Debianie i RHEL) oraz dost\u0119p do g\u0142\u00f3wnego cgroup v1 (na przyk\u0142ad Docker uruchamia kontenery w g\u0142\u00f3wnym cgroup RDMA). Atak jest r\u00f3wnie\u017c mo\u017cliwy przy posiadaniu przywilej\u00f3w CAP_SYS_ADMIN, w tym przypadku wsparcie dla przestrzeni nazw u\u017cytkownik\u00f3w i dost\u0119p do g\u0142\u00f3wnej hierarchii cgroup v1 nie jest wymagany. <\/p>\n
Opr\u00f3cz wychodzenia z izolowanego kontenera, luka ta pozwala r\u00f3wnie\u017c procesom uruchomionym przez u\u017cytkownika root bez «capabilities» lub kt\u00f3remukolwiek u\u017cytkownikowi z prawami CAP_DAC_OVERRIDE (do ataku wymagany jest dost\u0119p do pliku \/sys\/fs\/cgroup\/*\/release_agent, kt\u00f3ry nale\u017cy do roota), uzyska\u0107 dost\u0119p do wszystkich systemowych «capabilities». <\/p>\n
Zauwa\u017cono, \u017ce podatno\u015b\u0107 nie mo\u017ce by\u0107 wykorzystana przy stosowaniu mechanizm\u00f3w ochrony Seccomp, AppArmor lub SELinux do dodatkowej izolacji kontener\u00f3w, poniewa\u017c Seccomp blokuje dost\u0119p do wywo\u0142ania systemowego unshare(), a AppArmor i SELinux nie pozwalaj\u0105 na zamontowanie cgroupfs w trybie zapisu. \n \u0179r\u00f3d\u0142o: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
![\"Luka](\"\/wp-content\/uploads\/2022\/03\/710b37582c444cc4be7d6ae4695c8afe.jpg\")
<\/center> <\/p>\n