Detailer vun enger Schwachstelle (CVE-2022-0492) an der Ëmsetzung vum cgroups v1 Ressourcebegrenzungsmechanismus am Linux Kernel, dee ka benotzt ginn fir isoléiert Container ze flüchten, goufen opgedeckt. De Problem ass zënter Linux Kernel 2.6.24 präsent a gouf an Kernel Releases 5.16.12, 5.15.26, 5.10.97, 5.4.177, 4.19.229, 4.14.266, a 4.9.301 fixéiert. Dir kënnt d'Publikatioune vu Packageupdates an Distributiounen op dëse Säiten verfollegen: Debian, SUSE, Ubuntu, RHEL, Fedora, Gentoo, Arch Linux.
D'Schwachheet ass wéinst engem Logikfehler am release_agent Datei Handler deen net korrekt Kontrollen ausféiert wann de Handler mat voller Privilegien leeft. D'release_agent Datei gëtt benotzt fir de Programm ze definéieren fir vum Kernel auszeféieren wann e Prozess an enger cgroup ofgeschloss gëtt. Dëse Programm leeft als Root a mat all "Fäegkeeten" am Root Nummraum. Et gouf ugeholl datt nëmmen den Administrateur Zougang zu der release_agent Astellung hat, awer a Wierklechkeet waren d'Schecken limitéiert fir den Zougang zum Root Benotzer ze ginn, wat net ausgeschloss huet datt d'Astellung vum Container geännert gëtt oder vun engem Root Benotzer ouni Administrator Rechter (CAP_SYS_ADMIN) ).
Virdru wier esou eng Feature net als Schwachstelle ugesi ginn, awer d'Situatioun huet sech geännert mat der Erscheinung vu Benotzernummraim (Benotzernummraim), déi Iech erlaben separat Root Benotzer an Containeren ze kreéieren déi net mam Root Benotzer vun der iwwerlappt. Haaptentwéckler Ëmwelt. Deementspriechend, fir en Attack ass et genuch fir Ären release_agent Handler an engem Container ze verbannen, deen säin eegene Root Benotzer an engem separaten User ID Raum huet, deen, nodeems de Prozess ofgeschloss ass, mat voller Privilegien vum Haaptëmfeld ausgefouert gëtt.
Par défaut ass cgroupfs an engem Container am Read-only Modus montéiert, awer et gëtt kee Problem dës Pseudofs am Schreifmodus nei ze montéieren wann Dir CAP_SYS_ADMIN Rechter hutt oder andeems Dir en nestéierte Container mat engem separaten Benotzernummraum erstellt mat dem Unshare System Uruff, an deem CAP_SYS_ADMIN Rechter si fir den erstallten Container verfügbar.
Den Attack kann duerchgefouert ginn wann Dir Root Privilegien an engem isoléierte Container hutt oder wann Dir e Container leeft ouni den no_new_privs Fändel, wat verbitt zousätzlech Privilegien ze kréien. De System muss Ënnerstëtzung fir Benotzernummraim aktivéiert hunn (Standard aktivéiert an Ubuntu a Fedora, awer net an Debian a RHEL aktivéiert) an Zougang zu der Root cgroup v1 hunn (zum Beispill Docker leeft Container an der Root RDMA cgroup). Den Attack ass och méiglech wann Dir CAP_SYS_ADMIN Privilegien hutt, an deem Fall Ënnerstëtzung fir Benotzernummraim an Zougang zu der cgroup v1 Root Hierarchie net erfuerderlech sinn.
Zousätzlech fir aus engem isoléierte Container ze flüchten, erlaabt d'Vulnerabilitéit och Prozesser, déi vun engem Root Benotzer ouni "Fäegkeeten" gestart ginn oder all Benotzer mat CAP_DAC_OVERRIDE Rechter (den Attack erfuerdert Zougang zu der Datei /sys/fs/cgroup/*/release_agent, wat ass Besëtz vun der Root) fir Zougang zu all systemesche "Fäegkeeten" ze kréien.
Et gëtt bemierkt datt d'Schwachheet net exploitéiert ka ginn wann Dir de Seccomp, AppArmor oder SELinux Schutzmechanismen fir zousätzlech Isolatioun vu Container benotzt, well Seccomp den Zougang zum unshare () System Uruff blockéiert, an AppArmor an SELinux erlaben net Montéierung vu cgroupfs am Schreifmodus.
Source: opennet.ru
