En sårbarhed i cgroups v1, der tillader at forlade en isoleret container

Detaljer om sårbarheden (CVE-2022-0492) i implementeringen af ressourcebegrænsningsmekanismen cgroups v1 i Linux-kernen er blevet afsløret. Denne sårbarhed kan bruges til at undslippe isolerede containere. Problemet opstår fra Linux-kernen version 2.6.24 og er blevet rettet i kernel-versioner 5.16.12, 5.15.26, 5.10.97, 5.4.177, 4.19.229, 4.14.266 og 4.9.301. Opdateringer af pakker i distributionerne kan følges på følgende sider: Debian, SUSE, Ubuntu, RHEL, Fedora, Gentoo, Arch Linux.

Sårbarheden skyldes en logisk fejl i håndteringen af filen release_agent, hvilket medførte, at nødvendige kontroller ikke blev udført, når håndteringen blev kørt med fulde rettigheder. Filen release_agent bruges til at definere programmet, som kernen kører ved afslutning af en proces i cgroup. Dette program kører med root-rettigheder og alle ‘capabilities’ i det rod-namespac. Det var meningen, at kun administratoren skulle have adgang til indstillingen af release_agent, men i praksis var kontrolmekanismen begrænset til at give adgang til brugeren root, hvilket ikke udelukkede ændringer af indstillingen fra en container eller af brugeren root uden administratorrettigheder (CAP_SYS_ADMIN).

Tidligere ville en sådan karakteristika ikke være blevet opfattet som en sårbarhed, men situationen har ændret sig med introduktionen af user namespaces, som gør det muligt at oprette separerede root-brugere i containere, der ikke krydser over med root-brugerens konto i hovedmiljøet. Derfor er det tilstrækkeligt at tilslutte sin egen release_agent-handler i en container, der har sin egen root-bruger i et separat user namespace, som efter afslutningen af processen vil blive udført med fulde privilegier i hovedmiljøet.

Som standard er cgroupfs monteret i containeren i skrivebeskyttet tilstand, men der er ikke problemer med at remontere dette pseudofilsystem i skrivebar tilstand, hvis man har CAP_SYS_ADMIN-rettigheder, eller ved at oprette en indlejret container med et separat user namespace via systemkaldet unshare, hvor de nødvendige CAP_SYS_ADMIN-rettigheder er tilgængelige for den oprettede container.

En sårbarhed i cgroups v1, der tillader at forlade en isoleret container

Angrebet kan finde sted, hvis der er root-rettigheder i en isoleret container eller ved at starte en container uden no_new_privs-flaget, der forhindrer opnåelse af yderligere privilegier. Systemet skal have understøttelse af user namespaces aktiveret (som standard aktiveret i Ubuntu og Fedora, men ikke i Debian og RHEL) og have adgang til root cgroup v1 (for eksempel starter Docker containere i root RDMA cgroup). Angrebet er også muligt med privilegierne CAP_SYS_ADMIN, i dette tilfælde er understøttelse af user namespaces og adgang til root cgroup v1-hierarkiet ikke nødvendigt.

Udover at forlade den isolerede container giver sårbarheden også processer, der kører som root uden "capabilities" eller enhver bruger med CAP_DAC_OVERRIDE-rettigheder, adgang til alle systemets "capabilities" (adgang til filen /sys/fs/cgroup/*/release_agent, som tilhører root, kræves for angrebet).

Det bemærkes, at sårbarheden ikke kan udnyttes, når der anvendes beskyttelsesmekanismerne Seccomp, AppArmor eller SELinux til yderligere isolering af containere, da Seccomp blokerer for adgang til systemopkaldet unshare(), og AppArmor samt SELinux forhindrer montering af cgroupfs i skrivebords-tilstand.

Kilde: opennet.ru

Køb pålidelig webhosting med DDoS-beskyttelse, VPS VDS-servere 🔥 Køb pålidelig webhosting med DDoS-beskyttelse, VPS VDS-servere | ProHoster