CVE-2022-0492: ketverius metus egzistavusi branduolio skylė, kuri vis dar leidžia ištrūkti iš konteinerių

Įsivaizduokite: WordPress veikia Docker konteineryje, priekyje — nginx kaip reverse proxy, viskas užrakinta su nftables. Konteineris izoliuotas — kas galėtų nutikti? Užpuolikas randa pažeidžiamą įskiepį, gauna shell konteinerio viduje, ir po kelių sekundžių jis jau yra root ant hosto. Ne todėl, kad įsilaužė į Docker. O todėl, kad jūsų serverio branduolys turi CVE-2022-0492 — klaidą, pataisytą dar 2022 metais, kurią CISA įtraukė į Known Exploited Vulnerabilities katalogą 2026 m. birželio 2 d. Įtraukė — nes šiuo metu ji aktyviai išnaudojama. Tokiuose serveriuose kaip jūsų.

KAS NUTIKO

CVE-2022-0492 yra pažeidžiamumas funkcijoje cgroup_release_agent_write, esančioje faile kernel/cgroup/cgroup-v1.c. CVSS 7.8 (High), CWE-862 (Missing Authorization). Jį atrado Yiqi Sun ir Kevin Wang iš Huawei, atskleidimas įvyko 2022 m. vasarį. Pataisymas išleistas tuo pačiu metu — branduolio versijoje 5.17-rc3. Atrodytų, istorija baigėsi prieš ketverius metus.

Tačiau 2026 m. birželio 2 d. CISA įtraukė CVE-2022-0492 į KEV katalogą su terminu federalinėms agentūroms — birželio 5 d. Patekimas į KEV reiškia patvirtintą aktyvų išnaudojimą realiose atakose. Ketveri metai po pataisymo — ir klaida vis dar veikia nepataisiose sistemose. Priežastis paprasta: legacy serveriai be branduolio atnaujinimo proceso, embedded įrenginiai su užšaldytais branduoliais ir konteinerių hostai, kuriuose atnaujindavo konteinerius, bet pamiršdavo hosto branduolį.

KAS YRA CGROUPS V1 IR RELEASE_AGENT

Control groups (cgroups) — tai Linux branduolio mechanizmas, apribojantis ir stebintis resursų naudojimą (CPU, atmintis, tinklas) procesų grupei. Ant cgroups pastatyti visi konteineriai: Docker, Kubernetes ir LXC naudoja cgroups izoliacijai. Yra dvi versijos: cgroups v1 (senesnė, vis dar plačiai naudojama) ir cgroups v2 (nauja, vieninga hierarchija). CVE-2022-0492 paveikia tik v1.

cgroups v1 turi mechanizmą release_agent — specialų failą, į kurį administratorius gali įrašyti kelią iki programos. Branduolys tą programą paleidžia automatiškai, kai cgroup tampa tuščia, t. y. visi procesai joje baigė darbą. Paleidžia kaip root, už bet kokių namespace apribojimų ribų. Tai teisėta funkcija automatiniam resursų išvalymui. Įsivaizduokite valytoją su universaliu raktu: jis ateina kai visi išeina ir atlieka savo darbą. Problema — kas gali palikti jam nurodymus.

KAIP VEIKIA KLAIDA

Klaidos esmė — trūkstama teisių patikra rašant į failą release_agent. Prieš pataisymą branduolys netikslino, ar procesas, rašantis kelią į release_agent, turi teisę CAP_SYS_ADMIN pradiniame (hosto) namespace. Tai ir yra CWE-862: trūkstama autorizacijos patikra.

Išnaudojimo kelias eina per user namespaces. Linux leidžia neprivegilegijuotam procesui sukurti naują user namespace naudojant unshare, kuriame tas procesas gauna CAP_SYS_ADMIN — tačiau tik to namespace viduje. Toliau procesas prijungia cgroupfs naujame namespace ir į release_agent įrašo kelią iki bet kokio skripto. Branduolys netikrina, ar CAP_SYS_ADMIN buvo gauta konteinerinio namespace viduje, o ne pradiniame. Kai cgroup ištuštėja — branduolys paleidžia skriptą kaip root ant hosto.

KAIP TAI IŠNAUDOJAMA

Užpuolikas, gavęs shell konteinerio viduje, vykdo tokią seką. Sukuriamas naujas user namespace — neprivegilegijuotas procesas gauna jame CAP_SYS_ADMIN, bet tik to namespace ribose. Prijungiamas cgroupfs, sukuriama antrinė cgroup, o į šakninės cgroup failą release_agent įrašomas kelias iki backdoor skripto. Įjungiamas notify_on_release sukurtai cgroup, procesas joje baigia darbą — cgroup ištuštėjo, branduolys iškviečia release_agent. Skriptas vykdomas kaip root hosto kontekste, aplenkiant visus konteinerio namespace apribojimus.

Svarbu suprasti: norint išnaudoti pažeidžiamumą per user namespaces, nereikia būti root konteinerio viduje. Pakanka neprivegilegijuoto vartotojo — jei tik hosto sistemoje įjungti user namespaces, o jie įjungti pagal numatytuosius nustatymus Ubuntu, Debian ir daugumoje distribucijų. Root procesui konteinerio viduje — pavyzdžiui, nginx, veikiančiam kaip root — reikalavimai dar mažesni.

KAS NUTINKA TOLIAU — PRIKLAUSO NUO KONFIGŪRACIJOS

Rezultatas priklauso nuo to, kiek hardened jūsų konteinerių aplinka. Jei konteineris paleistas su AppArmor, SELinux enforcing režimu arba Seccomp — jie blokuoja reikiamus sisteminius iškvietimus (cgroupfs prijungimą, unshare) dar prieš tai, kai ataka gali progresuoti. Docker pagal numatytuosius nustatymus taiko seccomp profilį, kuris teoriškai apriboja šias operacijas — bet tik jei konteineris nepaleistas su --privileged, --security-opt seccomp=unconfined arba --cap-add SYS_ADMIN.

Jei konteineris paleistas be papildomų apsaugos priemonių — arba su susilpnintais profiliais, kas dažnai pasitaiko CI/CD aplinkose, kūrimo aplinkose ir „greituose” diegimuose — išnaudojimas pavyksta ir baigiasi visu hosto kompromitavimu. Kubernetes aplinkoje užpuolikas, perėmęs vieną pod ant mazgo su cgroups v1, gali kompromituoti visus kitus to mazgo pod ir judėti toliau po klasterį.

REALI ATAKOS GRANDINĖ

Tipinis šiuo metu išnaudojamas scenarijus: WordPress veikia Docker konteineryje. Užpuolikas randa pažeidžiamą įskiepį — RCE arba failo įkėlimo pažeidžiamumą — ir gauna shell kaip www-data konteinerio viduje. Hostas veikia Ubuntu 20.04 su branduoliu, kuris neatnaujintas nuo diegimo prieš dvejus metus. cgroups v1 aktyvus, AppArmor nesukonfigūruotas konteineriams, Seccomp nepatobulintas. Per CVE-2022-0492 užpuolikas per kelias sekundes gauna root ant hosto, nuskaito /etc/shadow, įdiegia SSH backdoor ir gauna nuolatinę prieigą prie serverio. Konteineris tuo metu toliau veikia — išoriškai niekas nesugedo, jokių įspėjimų.

CHRONOLOGIJA

2021 m. lapkritis — Aqua Security Team Nautilus tyrėjai fiksuoja pirmą realų container escape technikos per release_agent išnaudojimą gamtoje. Atkreipkite dėmesį: dar be CVE, dar be pataisymo — tiesiog tyliai veikiantis eksploitas realiose atakose. 2022 m. vasario 4 d. — Linux atskleidžia CVE-2022-0492, branduolio versijoje 5.17-rc3 išleidžiamas pataisymas. 2022 m. kovas — Ubuntu, Red Hat, Debian išleidžia atnaujintus branduolius. Ar visi atsinaujino? Ne. 2026 m. birželio 2 d. — CISA įtraukia CVE-2022-0492 į KEV su terminu JAV federalinėms agentūroms birželio 5 d. Praėjo ketveri metai nuo pataisymo. Atakos tęsiasi. Tai ne anomalija — tai standartinis rezultatas nepataisose sistemose.

KAIP TAI IŠGYVENO 4+ METUS

Pažeidžiamumas egzistavo branduolyje nuo pat user namespaces atsiradimo — funkcionalumo, pridėto Linux 3.8 versijoje 2013 m. Beveik dešimt metų. Išnaudojimo technika per release_agent saugumo bendruomenėje buvo žinoma gerokai prieš 2022 m.: 2019 m. liepą Google Project Zero tyrėjas Felix Wilhelm paskelbė container escape proof-of-concept, naudojant šią funkciją prieš privilegijuotus konteinerius. Visi žinojo, kad release_agent vykdomas kaip root. Tačiau buvo manoma: norint ten rašyti, reikia CAP_SYS_ADMIN hosto namespace. Niekas netikslino, ar kodas tai tikrina.

Pataisymas pasirodė esąs vienos eilutės. Vienas ns_capable(ns, CAP_SYS_ADMIN) iškvietimas tinkamoje vietoje — commit 24f6008564183aa120d07c03d9289519c2fe02af Torvalds repozitorijuje. Dešimt metų pažeidžiamumo — viena eilutė pataisymui. Palo Alto Unit 42 pavadino jį „vienu iš paprasčiausių Linux privilege escalation atradimų pastaruoju metu” — ir tai nėra komplimentas branduolio kūrėjams. Tai priminimas, kad patys pavojingiausi klaidai dažnai atrodo kaip nuobodžios loginės klaidos.

KODĖL TAI VIS DAR AKTUALU

CVE patekimas į KEV praėjus ketveriems metams po pataisymo — tai signalas apie problemos mastą. Atakos vektorius yra lokalus, tačiau konteinerių kontekste „lokalus” reiškia „gavau shell bet kuriame hosto konteineryje”. O gauti shell web konteineryje per pažeidžiamą WordPress įskiepį jau seniai nėra sudėtinga užduotis. Reali grėsmės modelis atrodo taip: CVE įskiepyje → RCE konteinerio viduje → CVE-2022-0492 → root ant hosto → visiškas visų konteinerių ir duomenų kontrolė.

Ypač pažeidžiami konteinerių hostai, kuriuose „atnaujindavo programas, bet ne branduolį” — tai dažna klaida. Docker paveikslėliai reguliariai perstatomi, o apt upgrade ant hosto su paskesniu reboot atliekamas kartą per metus — jei apskritai atliekamas. Būtent tokios sistemos šiuo metu yra taikinyje.

KAIP TO IŠVENGTI ATEITYJE

Pagrindinis CVE-2022-0492 pamoka griežta: kernel hardening ir container hardening — du atskiri sluoksniai, ir abu reikalauja atskiro pataisymo proceso. Paveikslėliai perstatomi per pipeline; hosto branduolys tyliai lieka be dėmesio mėnesiais. Būtent tie hostai šiuo metu taikinyje.

Sukonfigūruokite automatinius branduolio atnaujinimus. Ubuntu sistemoje tai daroma per unattended-upgrades — paketas greičiausiai jau įdiegtas, tačiau saugumo atnaujinimai su automatiniu reboot turi būti įjungti tiesiogiai:

sudo dpkg-reconfigure -plow unattended-upgrades

Komanda atvers interaktyvų dialogą — pasirinkite „Yes”. Kad leistumėte automatinį reboot (pavyzdžiui, 02:00), pridėkite į /etc/apt/apt.conf.d/50unattended-upgrades:

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "02:00";

RHEL šeimos sistemose atitikmuo — dnf-automatic. Įdiekite paketą ir įjunkite laikmatį:

sudo dnf install -y dnf-automatic
sudo systemctl enable --now dnf-automatic.timer

Prenumeruokite CISA KEV srautą — kai CVE ten patenka, tai nebėra „reikėtų kažkada atnaujinti”. Tai reiškia, kad aktyvus išnaudojimas vyksta dabar. Ir kaip ilgalaikė užduotis — migracija į cgroups v2: naujoje architektūroje release_agent mechanizmo nėra, todėl visa ši atakų klasė tiesiog išnyksta.

ATNAUJINIMAS

Pirmiausia patikrinkite branduolio versiją ir cgroups būseną ant hosto. Komanda uname -r parodys šiuo metu veikiantį branduolį. Ubuntu 22.04 LTS (jammy) ir Ubuntu 24.04 LTS (noble) nepaveiktos — jos išleistos jau su pataisytais branduoliais. Ubuntu 20.04 LTS (focal) sistemoje pataisymas įtrauktas nuo branduolio 5.4.0-105-generic (2022 m. kovas): jei turite senesnį — sistema pažeidžiama. Ubuntu 18.04 LTS (bionic) — nuo branduolio 4.15.0-173-generic.

uname -r

Patikrinti, ar naudojate cgroups v1 ar v2, galite žemiau pateikta komanda. cgroups v1 sistemoje pamatysite daug atskirų katalogų — cpu, memory, devices, blkio ir t. t. — kiekvieną posistemei. cgroups v2 sistemoje — vieningą hierarchiją: arba vieną katalogą unified, arba tiesiog failus kaip cgroup.controllers šakninėje direktorijoje. Jei matote v2 — pažeidžiamumas netaikomas.

ls /sys/fs/cgroup/

Branduolio atnaujinimui Ubuntu/Debian sistemose:

sudo apt update && sudo apt upgrade -y
sudo reboot

RHEL/AlmaLinux/Rocky Linux sistemose:

sudo dnf clean metadata && sudo dnf upgrade -y kernel
sudo reboot

Po reboot dar kartą paleiskite uname -r ir įsitikinkite, kad branduolys atnaujintas. Branduolio atnaujinimas be reboot neturi efekto — senas branduolys toliau veikia atmintyje iki paleidimo iš naujo.

Patikrinti, ar jūsų Docker konteineris apsaugotas nuo išnaudojimo, galima Unit 42 (Palo Alto Networks) skelbiamu skriptu CVE-2022-0492-Checker, prieinamu GitHub platformoje. Jis tikrina, ar konteineris gali prijungti cgroupfs ir rašyti į release_agent, ir pateikia aiškų atsakymą: pažeidžiama ar ne. Jei branduolio atnaujinti laikinai neįmanoma — įsitikinkite, kad konteineriai veikia su AppArmor arba SELinux enforcing režime, ir nenaudoja --privileged ar --security-opt seccomp=unconfined nustatymų.

IŠVADOS

CVE-2022-0492 — geras pavyzdys, kodėl „pataisymas išleistas” nereiškia „esate apsaugoti”. Seno CVE patekimas į CISA KEV katalogą — tai ne žinia apie naują pažeidžiamumą. Tai žinia, kad nepataisiose sistemose jis aktyviai išnaudojamas dabar. Jei turite konteinerių hostų su 2022 metų senesnio branduoliu ir cgroups v1 — patikrinkite ir atnaujinkite šiandien. Komanda uname -r + apt upgrade + reboot — trys žingsniai, kurie uždaro realų atakos vektorių.