Er zijn details bekendgemaakt van een kwetsbaarheid (CVE-2022-0492) in de implementatie van het cgroups v1 resourcebeperkingsmechanisme in de Linux-kernel, dat kan worden gebruikt om aan geïsoleerde containers te ontsnappen. Het probleem is aanwezig sinds Linux-kernel 2.6.24 en is opgelost in kernelreleases 5.16.12, 5.15.26, 5.10.97, 5.4.177, 4.19.229, 4.14.266 en 4.9.301. U kunt de publicaties van pakketupdates in distributies volgen op deze pagina's: Debian, SUSE, Ubuntu, RHEL, Fedora, Gentoo, Arch Linux.
Het beveiligingslek is te wijten aan een logische fout in de bestandshandler release_agent die er niet in slaagt de juiste controles uit te voeren wanneer de handler met volledige bevoegdheden wordt uitgevoerd. Het release_agent-bestand wordt gebruikt om het programma te definiëren dat door de kernel moet worden uitgevoerd wanneer een proces in een cgroup wordt beëindigd. Dit programma draait als root en met alle “mogelijkheden” in de rootnaamruimte. Er werd aangenomen dat alleen de beheerder toegang had tot de instelling release_agent, maar in werkelijkheid bleven de controles beperkt tot het verlenen van toegang aan de rootgebruiker, wat niet uitsluit dat de instelling wordt gewijzigd vanuit de container of door een rootgebruiker zonder beheerdersrechten (CAP_SYS_ADMIN ).
Voorheen zou een dergelijke functie niet als een kwetsbaarheid worden gezien, maar de situatie is veranderd met de komst van gebruikersnaamruimten (gebruikersnaamruimten), waarmee u afzonderlijke rootgebruikers kunt maken in containers die niet overlappen met de rootgebruiker van de belangrijkste omgeving. Dienovereenkomstig is het voor een aanval voldoende om uw release_agent-handler aan te sluiten in een container met een eigen rootgebruiker in een aparte gebruikers-ID-ruimte, die, na voltooiing van het proces, zal worden uitgevoerd met volledige rechten van de hoofdomgeving.
Standaard wordt cgroupfs aangekoppeld in een container in de alleen-lezen-modus, maar er is geen probleem om deze pseudofs opnieuw aan te koppelen in de schrijfmodus als je CAP_SYS_ADMIN-rechten hebt of door een geneste container te maken met een aparte gebruikersnaamruimte met behulp van de unshare-systeemaanroep, waarin CAP_SYS_ADMIN-rechten zijn beschikbaar voor de gemaakte container.
De aanval kan worden uitgevoerd als je root-rechten hebt in een geïsoleerde container of als je een container draait zonder de vlag no_new_privs, wat het verkrijgen van extra rechten verbiedt. Het systeem moet ondersteuning voor gebruikersnaamruimten ingeschakeld hebben (standaard ingeschakeld in Ubuntu en Fedora, maar niet geactiveerd in Debian en RHEL) en toegang hebben tot de root-cgroup v1 (docker draait bijvoorbeeld containers in de root-RDMA-cgroup). De aanval is ook mogelijk als u CAP_SYS_ADMIN-rechten heeft, in welk geval ondersteuning voor gebruikersnaamruimten en toegang tot de cgroup v1-hoofdhiërarchie niet vereist zijn.
Naast het ontsnappen uit een geïsoleerde container, staat het beveiligingslek ook toe dat processen worden gestart door een rootgebruiker zonder "mogelijkheden" of door een gebruiker met CAP_DAC_OVERRIDE-rechten (de aanval vereist toegang tot het bestand /sys/fs/cgroup/*/release_agent, dat is eigendom van root) om toegang te krijgen tot alle systemische “mogelijkheden”.
Opgemerkt wordt dat de kwetsbaarheid niet kan worden misbruikt bij gebruik van de Seccomp-, AppArmor- of SELinux-beschermingsmechanismen voor extra isolatie van containers, aangezien Seccomp de toegang tot de unshare() systeemaanroep blokkeert, en AppArmor en SELinux het aankoppelen van cgroupfs in de schrijfmodus niet toestaan.
Bron: opennet.ru