Besonderhede van 'n kwesbaarheid (CVE-2022-0492) in die implementering van die cgroups v1 hulpbronbeperkingsmeganisme in die Linux-kern, wat gebruik kan word om geïsoleerde houers te ontsnap, is bekend gemaak. Die probleem bestaan sedert Linux-kern 2.6.24 en is reggestel in kernvrystellings 5.16.12, 5.15.26, 5.10.97, 5.4.177, 4.19.229, 4.14.266 en 4.9.301. U kan die publikasies van pakketopdaterings in verspreidings op hierdie bladsye volg: Debian, SUSE, Ubuntu, RHEL, Fedora, Gentoo, Arch Linux.
Die kwesbaarheid is te wyte aan 'n logiese fout in die release_agent-lêerhanteerder wat nie behoorlike kontrole uitvoer wanneer die hanteerder met volle voorregte uitgevoer word nie. Die release_agent-lêer word gebruik om die program te definieer wat deur die kern uitgevoer moet word wanneer 'n proses in 'n cgroup beëindig word. Hierdie program loop as wortel en met alle "vermoëns" in die wortelnaamruimte. Daar is aanvaar dat slegs die administrateur toegang tot die release_agent-instelling gehad het, maar in werklikheid was die kontroles beperk tot die toekenning van toegang aan die wortelgebruiker, wat nie uitgesluit het dat die instelling vanaf die houer of deur 'n wortelgebruiker sonder administrateurregte verander word nie (CAP_SYS_ADMIN ).
Voorheen sou so 'n kenmerk nie as 'n kwesbaarheid beskou gewees het nie, maar die situasie het verander met die koms van gebruikernaamruimtes (gebruikersnaamruimtes), wat jou toelaat om afsonderlike wortelgebruikers te skep in houers wat nie oorvleuel met die wortelgebruiker van die hoof omgewing. Gevolglik, vir 'n aanval, is dit genoeg om jou release_agent-hanteerder te koppel aan 'n houer wat sy eie wortelgebruiker het in 'n aparte gebruikers-ID-spasie, wat, na voltooiing van die proses, uitgevoer sal word met volle voorregte van die hoofomgewing.
By verstek word cgroupfs in 'n houer in leesalleenmodus gemonteer, maar daar is geen probleem om hierdie pseudofs in skryfmodus weer te monteer as jy CAP_SYS_ADMIN regte het of deur 'n geneste houer met 'n aparte gebruikernaamruimte te skep deur die unshare-stelseloproep te gebruik, waarin CAP_SYS_ADMIN regte is beskikbaar vir die geskepde houer.
Die aanval kan uitgevoer word as jy wortelregte in 'n geïsoleerde houer het of wanneer 'n houer sonder die no_new_privs-vlag bestuur word, wat die verkryging van bykomende voorregte verbied. Die stelsel moet ondersteuning hê vir gebruikernaamspasies geaktiveer (by verstek geaktiveer in Ubuntu en Fedora, maar nie in Debian en RHEL geaktiveer nie) en toegang hê tot die wortel cgroup v1 (byvoorbeeld, Docker laat houers in die wortel RDMA cgroup uit). Die aanval is ook moontlik as jy CAP_SYS_ADMIN-regte het, in welke geval ondersteuning vir gebruikernaamruimtes en toegang tot die cgroup v1-wortelhiërargie nie vereis word nie.
Benewens ontsnapping uit 'n geïsoleerde houer, laat die kwesbaarheid ook prosesse toe wat deur 'n wortelgebruiker sonder "vermoëns" of enige gebruiker met CAP_DAC_OVERRIDE-regte geloods word (die aanval vereis toegang tot die lêer /sys/fs/cgroup/*/release_agent, wat is deur wortel besit) om toegang te verkry tot alle sistemiese "vermoëns".
Daar word opgemerk dat die kwesbaarheid nie uitgebuit kan word wanneer die Seccomp-, AppArmor- of SELinux-beskermingsmeganismes gebruik word vir bykomende isolasie van houers nie, aangesien Seccomp toegang tot die unshare()-stelseloproep blokkeer, en AppArmor en SELinux nie die montering van cgroupfs in skryfmodus toelaat nie.
Bron: opennet.ru