Noen dager siden nyheten ble sluppet detaljer er avslørt en sårbarhet som ble funnet i implementeringen av mekanismen ressursbegrensning cgroup v1 i Linux-kjernen som allerede er katalogisert under CVE-2022-0492.
Denne sårbarheten fant se kan brukes til å gå ut av isolerte beholdere og det er detaljert at problemet har vært tilstede siden Linux-kjernen 2.6.24.
I blogginnlegget er det nevnt at sårbarheten skyldes en logisk feil i release_agent-filbehandleren, så de riktige kontrollene ble ikke utført når driveren ble kjørt med fulle tillatelser.
Filen release_agent brukes til å definere programmet som kjernen kjører når en prosess ender i en c-gruppe. Dette programmet kjører som root med all "kapasitet" i rotnavneområdet. Bare administratoren skulle ha tilgang til release_agent-konfigurasjonen, men i virkeligheten var kontrollene begrenset til å gi tilgang til root-brukeren, noe som ikke utelukket endring av konfigurasjonen fra containeren eller av den ikke-administrative root-brukeren (CAP_SYS_ADMIN ) .
tidligere, denne funksjonen ville ikke blitt oppfattet som en sårbarhet, men situasjonen har endret seg med bruken av brukeridentifikatornavnerom (brukernavnerom), som lar deg lage separate rotbrukere i beholdere som ikke overlapper med rotbrukeren til hovedmiljøet.
Følgelig for et angrep er det nok i en container som har sin egen root-bruker i et eget bruker-ID-rom for å plugge inn release_agent-behandleren, som, når prosessen er fullført, vil kjøre med alle privilegiene til det overordnede miljøet.
Som standard er cgroupfs montert i en skrivebeskyttet beholder, men det er ikke noe problem å remontere disse pseudofene i skrivemodus med CAP_SYS_ADMIN-rettigheter eller ved å lage en nestet beholder med et eget brukernavnområde ved å bruke systemoppfordringen for stoppdeling, der CAP_SYS_ADMIN-rettigheter er tilgjengelige for den opprettede beholderen.
Angrepet kan gjøres ved å ha root-privilegier i en isolert beholder eller ved å kjøre beholderen uten no_new_privs-flagget, som forbyr å få ytterligere privilegier.
Systemet må ha støtte for navneområder aktivert bruker (aktivert som standard på Ubuntu og Fedora, men ikke aktivert på Debian og RHEL) og har tilgang til root v1 cgroup (f.eks. Docker kjører containere i RDMA root cgroup). Angrepet er også mulig med CAP_SYS_ADMIN-privilegier, i så fall er det ikke nødvendig med støtte for brukernavneområder og tilgang til rothierarkiet til cgroup v1.
I tillegg til å bryte ut av den isolerte beholderen, tillater sårbarheten også prosesser startet av root-brukeren uten "capability" eller noen bruker med CAP_DAC_OVERRIDE-rettigheter (angrepet krever tilgang til /sys/fs/cgroup/*/release_agent-filen som eies av root) for å få tilgang til alle "funksjonene" til systemet.
Bortsett fra containere, kan sårbarheten også tillate rotvertsprosesser uten evner, eller ikke-rotvertsprosesser med CAP_DAC_OVERRIDE-funksjonen, å eskalere privilegier til fulle evner. Dette kan tillate angripere å omgå et herdetiltak som brukes av visse tjenester, som fjerner evner i et forsøk på å begrense virkningen hvis et kompromiss inntreffer.
Enhet 42 anbefaler brukere å oppgradere til en fast kjerneversjon. For de som kjører containere, aktiver Secomp og sørg for at AppArmor eller SELinux er aktivert. Prisma Cloud-brukere kan henvise til "Prisma Cloud Protections"-delen for å se kompensasjonene som tilbys av Prisma Cloud.
Merk at sårbarheten ikke kan utnyttes når du bruker Seccomp, AppArmor eller SELinux beskyttelsesmekanismer for ytterligere beholderisolering, da Seccomp blokkerer unshare() systemkallet og AppArmor og SELinux ikke tillater at cgroupfs monteres i skrivemodus.
Til slutt er det verdt å nevne at det ble fikset i kjerneversjoner 5.16.12, 5.15.26, 5.10.97, 5.4.177, 4.19.229, 4.14.266 og 4.9.301. Du kan følge utgivelsen av pakkeoppdateringer i distribusjoner på disse sidene: Debian, SUSE, Ubuntu, RHEL, Fedora, Gentoo, Arch Linux.
Endelig hvis du er interessert i å vite mer om det, kan du sjekke detaljene i følgende lenke.