Paar dagen geleden het nieuws is vrijgegeven details zijn onthuld een kwetsbaarheid dat is gevonden bij de implementatie van het mechanisme beperking van middelen cgroep v1 in de Linux-kernel die al is gecatalogiseerd onder CVE-2022-0492.
Deze kwetsbaarheid is gevondene kan worden gebruikt om geïsoleerde containers te verlaten en het is gedetailleerd dat het probleem aanwezig is sinds Linux-kernel 2.6.24.
In de blogpost wordt vermeld dat de kwetsbaarheid is te wijten aan een logische fout in de bestandshandler release_agent, dus de juiste controles werden niet uitgevoerd wanneer het stuurprogramma met volledige machtigingen werd uitgevoerd.
het bestand release_agent wordt gebruikt om het programma te definiëren dat de kernel uitvoert wanneer een proces eindigt in een cgroup. Dit programma draait als root met alle "mogelijkheden" in de rootnaamruimte. Alleen de beheerder zou toegang hebben tot de release_agent-configuratie, maar in werkelijkheid waren de controles beperkt tot het verlenen van toegang aan de rootgebruiker, wat niet uitsloot dat de configuratie vanuit de container of door de niet-beheerdersrootgebruiker (CAP_SYS_ADMIN ) kon worden gewijzigd. .
eerder, deze functie zou niet als een kwetsbaarheid zijn gezien, maar de situatie is veranderd met de komst van gebruikersidentificatienaamruimten (gebruikersnaamruimten), waarmee u afzonderlijke rootgebruikers kunt maken in containers die niet overlappen met de rootgebruiker van de hoofdomgeving.
dienovereenkomstig voor een aanval is het voldoende in een container die zijn eigen root-gebruiker heeft in een aparte gebruikers-ID-ruimte om uw release_agent-handler in te pluggen, die, zodra het proces is voltooid, wordt uitgevoerd met alle privileges van de bovenliggende omgeving.
Standaard wordt cgroupfs aangekoppeld in een alleen-lezen container, maar het is geen probleem om deze pseudofs opnieuw te koppelen in de schrijfmodus met CAP_SYS_ADMIN-rechten of door een geneste container te maken met een aparte gebruikersnaamruimte met behulp van de systeemaanroep voor stoppen met delen, waarin CAP_SYS_ADMIN-rechten zijn beschikbaar voor de gemaakte container.
De aanval kan worden gedaan door rootrechten in een geïsoleerde container te hebben of door de container uit te voeren zonder de no_new_privs-vlag, die het verkrijgen van extra privileges verbiedt.
Het systeem moet ondersteuning voor naamruimten hebben ingeschakeld gebruiker (standaard ingeschakeld op Ubuntu en Fedora, maar niet ingeschakeld op Debian en RHEL) en toegang hebben tot de root v1 cgroup (bijvoorbeeld, Docker voert containers uit in de RDMA root-cgroup). De aanval is ook mogelijk met CAP_SYS_ADMIN-rechten, in welk geval ondersteuning voor gebruikersnaamruimten en toegang tot de roothiërarchie van cgroup v1 niet vereist is.
Naast het doorbreken van de geïsoleerde container, maakt de kwetsbaarheid het ook mogelijk processen te starten door de rootgebruiker zonder "capability" of een gebruiker met CAP_DAC_OVERRIDE-rechten (de aanval vereist toegang tot het /sys/fs/cgroup/*/release_agent-bestand dat eigendom is van root) om toegang te krijgen tot alle "mogelijkheden" van het systeem.
Afgezien van containers, kan het beveiligingslek ook root-hostprocessen zonder capaciteiten, of niet-roothostprocessen met de CAP_DAC_OVERRIDE-mogelijkheid, toestaan om privileges te escaleren naar volledige mogelijkheden. Hierdoor kunnen aanvallers een verhardingsmaatregel omzeilen die door bepaalde services wordt gebruikt, waardoor mogelijkheden worden verwijderd in een poging de impact te beperken als er een compromis optreedt.
Unit 42 raadt gebruikers aan om te upgraden naar een vaste kernelversie. Voor degenen die containers draaien, schakel Seccomp in en zorg ervoor dat AppArmor of SELinux is ingeschakeld. Prisma Cloud-gebruikers kunnen het gedeelte "Prisma Cloud Protections" raadplegen om de door Prisma Cloud geboden oplossingen te bekijken.
Merk op dat de kwetsbaarheid niet kan worden uitgebuit bij gebruik van Seccomp, AppArmor of SELinux beschermingsmechanismen voor extra containerisolatie, aangezien Seccomp de unshare() systeemaanroep blokkeert en AppArmor en SELinux niet toestaan dat cgroupfs in de schrijfmodus wordt aangekoppeld.
Ten slotte is het vermeldenswaard dat het werd opgelost in kernelversies 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 release van pakketupdates in distributies volgen op deze pagina's: Debian, SUSE, Ubuntu, RHEL, Fedora, Gentoo, Arch Linux.
Eindelijk als u er meer over wilt wetenkunt u de details in het volgende link.