\u012esivaizduokite: WordPress veikia Docker konteineryje, priekyje \u2014 nginx kaip reverse proxy, viskas u\u017erakinta su nftables. Konteineris izoliuotas \u2014 kas gal\u0117t\u0173 nutikti? U\u017epuolikas randa pa\u017eeid\u017eiam\u0105 \u012fskiep\u012f, gauna shell konteinerio viduje, ir po keli\u0173 sekund\u017ei\u0173 jis jau yra root ant hosto. Ne tod\u0117l, kad \u012fsilau\u017e\u0117 \u012f Docker. O tod\u0117l, kad j\u016bs\u0173 serverio branduolys turi CVE-2022-0492 \u2014 klaid\u0105, pataisyt\u0105 dar 2022 metais, kuri\u0105 CISA \u012ftrauk\u0117 \u012f Known Exploited Vulnerabilities katalog\u0105 2026 m. bir\u017eelio 2 d. \u012etrauk\u0117 \u2014 nes \u0161iuo metu ji aktyviai i\u0161naudojama. Tokiuose serveriuose kaip j\u016bs\u0173.<\/p>\n\n\n\n
KAS NUTIKO<\/strong><\/p>\n\n\n\n CVE-2022-0492 yra pa\u017eeid\u017eiamumas funkcijoje Ta\u010diau 2026 m. bir\u017eelio 2 d. CISA \u012ftrauk\u0117 CVE-2022-0492 \u012f KEV katalog\u0105 su terminu federalin\u0117ms agent\u016broms \u2014 bir\u017eelio 5 d. Patekimas \u012f KEV rei\u0161kia patvirtint\u0105 aktyv\u0173 i\u0161naudojim\u0105 realiose atakose. Ketveri metai po pataisymo \u2014 ir klaida vis dar veikia nepataisiose sistemose. Prie\u017eastis paprasta: legacy serveriai be branduolio atnaujinimo proceso, embedded \u012frenginiai su u\u017e\u0161aldytais branduoliais ir konteineri\u0173 hostai, kuriuose atnaujindavo konteinerius, bet pamir\u0161davo hosto branduol\u012f.<\/p>\n\n\n\n KAS YRA CGROUPS V1 IR RELEASE_AGENT<\/strong><\/p>\n\n\n\n Control groups (cgroups) \u2014 tai Linux branduolio mechanizmas, apribojantis ir stebintis resurs\u0173 naudojim\u0105 (CPU, atmintis, tinklas) proces\u0173 grupei. Ant cgroups pastatyti visi konteineriai: Docker, Kubernetes ir LXC naudoja cgroups izoliacijai. Yra dvi versijos: cgroups v1 (senesn\u0117, vis dar pla\u010diai naudojama) ir cgroups v2 (nauja, vieninga hierarchija). CVE-2022-0492 paveikia tik v1.<\/p>\n\n\n\n cgroups v1 turi mechanizm\u0105 KAIP VEIKIA KLAIDA<\/strong><\/p>\n\n\n\n Klaidos esm\u0117 \u2014 tr\u016bkstama teisi\u0173 patikra ra\u0161ant \u012f fail\u0105 I\u0161naudojimo kelias eina per user namespaces. Linux leid\u017eia neprivegilegijuotam procesui sukurti nauj\u0105 user namespace naudojant KAIP TAI I\u0160NAUDOJAMA<\/strong><\/p>\n\n\n\n U\u017epuolikas, gav\u0119s shell konteinerio viduje, vykdo toki\u0105 sek\u0105. Sukuriamas naujas user namespace \u2014 neprivegilegijuotas procesas gauna jame Svarbu suprasti: norint i\u0161naudoti pa\u017eeid\u017eiamum\u0105 per user namespaces, nereikia b\u016bti root konteinerio viduje. Pakanka neprivegilegijuoto vartotojo \u2014 jei tik hosto sistemoje \u012fjungti user namespaces, o jie \u012fjungti pagal numatytuosius nustatymus Ubuntu, Debian ir daugumoje distribucij\u0173. Root procesui konteinerio viduje \u2014 pavyzd\u017eiui, nginx, veikian\u010diam kaip root \u2014 reikalavimai dar ma\u017eesni.<\/p>\n\n\n\n KAS NUTINKA TOLIAU \u2014 PRIKLAUSO NUO KONFIG\u016aRACIJOS<\/strong><\/p>\n\n\n\n Rezultatas priklauso nuo to, kiek hardened j\u016bs\u0173 konteineri\u0173 aplinka. Jei konteineris paleistas su AppArmor, SELinux enforcing re\u017eimu arba Seccomp \u2014 jie blokuoja reikiamus sisteminius i\u0161kvietimus (cgroupfs prijungim\u0105, unshare) dar prie\u0161 tai, kai ataka gali progresuoti. Docker pagal numatytuosius nustatymus taiko seccomp profil\u012f, kuris teori\u0161kai apriboja \u0161ias operacijas \u2014 bet tik jei konteineris nepaleistas su Jei konteineris paleistas be papildom\u0173 apsaugos priemoni\u0173 \u2014 arba su susilpnintais profiliais, kas da\u017enai pasitaiko CI\/CD aplinkose, k\u016brimo aplinkose ir \u201egreituose” diegimuose \u2014 i\u0161naudojimas pavyksta ir baigiasi visu hosto kompromitavimu. Kubernetes aplinkoje u\u017epuolikas, per\u0117m\u0119s vien\u0105 pod ant mazgo su cgroups v1, gali kompromituoti visus kitus to mazgo pod ir jud\u0117ti toliau po klaster\u012f.<\/p>\n\n\n\n REALI ATAKOS GRANDIN\u0116<\/strong><\/p>\n\n\n\n Tipinis \u0161iuo metu i\u0161naudojamas scenarijus: WordPress veikia Docker konteineryje. U\u017epuolikas randa pa\u017eeid\u017eiam\u0105 \u012fskiep\u012f \u2014 RCE arba failo \u012fk\u0117limo pa\u017eeid\u017eiamum\u0105 \u2014 ir gauna shell kaip CHRONOLOGIJA<\/strong><\/p>\n\n\n\n 2021 m. lapkritis \u2014 Aqua Security Team Nautilus tyr\u0117jai fiksuoja pirm\u0105 real\u0173 container escape technikos per KAIP TAI I\u0160GYVENO 4+ METUS<\/strong><\/p>\n\n\n\n Pa\u017eeid\u017eiamumas egzistavo branduolyje nuo pat user namespaces atsiradimo \u2014 funkcionalumo, prid\u0117to Linux 3.8 versijoje 2013 m. Beveik de\u0161imt met\u0173. I\u0161naudojimo technika per Pataisymas pasirod\u0117 es\u0105s vienos eilut\u0117s. Vienas KOD\u0116L TAI VIS DAR AKTUALU<\/strong><\/p>\n\n\n\n CVE patekimas \u012f KEV pra\u0117jus ketveriems metams po pataisymo \u2014 tai signalas apie problemos mast\u0105. Atakos vektorius yra lokalus, ta\u010diau konteineri\u0173 kontekste \u201elokalus” rei\u0161kia \u201egavau shell bet kuriame hosto konteineryje”. O gauti shell web konteineryje per pa\u017eeid\u017eiam\u0105 WordPress \u012fskiep\u012f jau seniai n\u0117ra sud\u0117tinga u\u017eduotis. Reali gr\u0117sm\u0117s modelis atrodo taip: CVE \u012fskiepyje \u2192 RCE konteinerio viduje \u2192 CVE-2022-0492 \u2192 root ant hosto \u2192 visi\u0161kas vis\u0173 konteineri\u0173 ir duomen\u0173 kontrol\u0117.<\/p>\n\n\n\n Ypa\u010d pa\u017eeid\u017eiami konteineri\u0173 hostai, kuriuose \u201eatnaujindavo programas, bet ne branduol\u012f” \u2014 tai da\u017ena klaida. Docker paveiksl\u0117liai reguliariai perstatomi, o KAIP TO I\u0160VENGTI ATEITYJE<\/strong><\/p>\n\n\n\n Pagrindinis CVE-2022-0492 pamoka grie\u017eta: kernel hardening ir container hardening \u2014 du atskiri sluoksniai, ir abu reikalauja atskiro pataisymo proceso. Paveiksl\u0117liai perstatomi per pipeline; hosto branduolys tyliai lieka be d\u0117mesio m\u0117nesiais. B\u016btent tie hostai \u0161iuo metu taikinyje.<\/p>\n\n\n\n Sukonfig\u016bruokite automatinius branduolio atnaujinimus. Ubuntu sistemoje tai daroma per Komanda atvers interaktyv\u0173 dialog\u0105 \u2014 pasirinkite \u201eYes”. Kad leistum\u0117te automatin\u012f reboot (pavyzd\u017eiui, 02:00), prid\u0117kite \u012f RHEL \u0161eimos sistemose atitikmuo \u2014 Prenumeruokite CISA KEV sraut\u0105 \u2014 kai CVE ten patenka, tai neb\u0117ra \u201ereik\u0117t\u0173 ka\u017ekada atnaujinti”. Tai rei\u0161kia, kad aktyvus i\u0161naudojimas vyksta dabar. Ir kaip ilgalaik\u0117 u\u017eduotis \u2014 migracija \u012f cgroups v2: naujoje architekt\u016broje ATNAUJINIMAS<\/strong><\/p>\n\n\n\n Pirmiausia patikrinkite branduolio versij\u0105 ir cgroups b\u016bsen\u0105 ant hosto. Komanda Patikrinti, ar naudojate cgroups v1 ar v2, galite \u017eemiau pateikta komanda. cgroups v1 sistemoje pamatysite daug atskir\u0173 katalog\u0173 \u2014 Branduolio atnaujinimui Ubuntu\/Debian sistemose:<\/p>\n\n\n\n RHEL\/AlmaLinux\/Rocky Linux sistemose:<\/p>\n\n\n\n Po reboot dar kart\u0105 paleiskite Patikrinti, ar j\u016bs\u0173 Docker konteineris apsaugotas nuo i\u0161naudojimo, galima Unit 42 (Palo Alto Networks) skelbiamu skriptu I\u0160VADOS<\/strong><\/p>\n\n\n\n CVE-2022-0492 \u2014 geras pavyzdys, kod\u0117l \u201epataisymas i\u0161leistas” nerei\u0161kia \u201eesate apsaugoti”. Seno CVE patekimas \u012f CISA KEV katalog\u0105 \u2014 tai ne \u017einia apie nauj\u0105 pa\u017eeid\u017eiamum\u0105. Tai \u017einia, kad nepataisiose sistemose jis aktyviai i\u0161naudojamas dabar. Jei turite konteineri\u0173 host\u0173 su 2022 met\u0173 senesnio branduoliu ir cgroups v1 \u2014 patikrinkite ir atnaujinkite \u0161iandien. Komanda \u012esivaizduokite: WordPress veikia Docker konteineryje, priekyje \u2014 nginx kaip reverse proxy, viskas u\u017erakinta su nftables. Konteineris izoliuotas \u2014 kas gal\u0117t\u0173 nutikti? U\u017epuolikas randa pa\u017eeid\u017eiam\u0105 \u012fskiep\u012f, gauna shell konteinerio viduje, ir po keli\u0173 sekund\u017ei\u0173 jis jau yra root ant hosto. Ne tod\u0117l, kad \u012fsilau\u017e\u0117 \u012f Docker. O tod\u0117l, kad j\u016bs\u0173 serverio branduolys turi CVE-2022-0492 \u2014 klaid\u0105, pataisyt\u0105 dar 2022 metais, kuri\u0105 CISA \u012ftrauk\u0117 \u012f Known Exploited Vulnerabilities katalog\u0105 2026 m. bir\u017eelio 2 d. \u012etrauk\u0117 \u2014 nes \u0161iuo metu ji aktyviai i\u0161naudojama. Tokiuose serveriuose kaip j\u016bs\u0173. KAS NUTIKO CVE-2022-0492 yra pa\u017eeid\u017eiamumas funkcijoje cgroup_release_agent_write, esan\u010dioje faile kernel\/cgroup\/cgroup-v1.c. CVSS 7.8 (High), CWE-862 (Missing Authorization). J\u012f atrado Yiqi Sun ir Kevin Wang i\u0161 Huawei, atskleidimas \u012fvyko 2022 m. vasar\u012f. Pataisymas i\u0161leistas tuo pa\u010diu metu \u2014 branduolio versijoje 5.17-rc3. Atrodyt\u0173, istorija baig\u0117si prie\u0161 ketverius metus. Ta\u010diau 2026 m. bir\u017eelio 2 d. CISA \u012ftrauk\u0117 CVE-2022-0492 \u012f KEV katalog\u0105 su terminu federalin\u0117ms agent\u016broms \u2014 bir\u017eelio 5 d. Patekimas \u012f KEV rei\u0161kia patvirtint\u0105 aktyv\u0173 i\u0161naudojim\u0105 realiose atakose. Ketveri metai po pataisymo \u2014 ir klaida vis dar veikia nepataisiose sistemose. Prie\u017eastis paprasta: legacy serveriai be branduolio atnaujinimo proceso, embedded \u012frenginiai su u\u017e\u0161aldytais branduoliais ir konteineri\u0173 hostai, kuriuose atnaujindavo konteinerius, bet pamir\u0161davo hosto branduol\u012f. KAS YRA CGROUPS V1 IR RELEASE_AGENT Control groups (cgroups) \u2014 tai Linux branduolio mechanizmas, apribojantis ir stebintis resurs\u0173 naudojim\u0105 (CPU, atmintis, tinklas) proces\u0173 grupei. Ant cgroups pastatyti visi konteineriai: Docker, Kubernetes ir LXC naudoja cgroups izoliacijai. Yra dvi versijos: cgroups v1 (senesn\u0117, vis dar pla\u010diai naudojama) ir cgroups v2 (nauja, vieninga hierarchija). CVE-2022-0492 paveikia tik v1. cgroups v1 turi mechanizm\u0105 release_agent \u2014 special\u0173 fail\u0105, \u012f kur\u012f administratorius gali \u012fra\u0161yti keli\u0105 iki programos. Branduolys t\u0105 program\u0105 paleid\u017eia automati\u0161kai, kai cgroup tampa tu\u0161\u010dia, t. y. visi procesai joje baig\u0117 darb\u0105. Paleid\u017eia kaip root, u\u017e bet koki\u0173 namespace apribojim\u0173 rib\u0173. Tai teis\u0117ta funkcija automatiniam resurs\u0173 i\u0161valymui. \u012esivaizduokite valytoj\u0105 su universaliu raktu: jis ateina kai visi i\u0161eina ir atlieka savo darb\u0105. Problema \u2014 kas gali palikti jam nurodymus. KAIP VEIKIA KLAIDA Klaidos esm\u0117 \u2014 tr\u016bkstama teisi\u0173 patikra ra\u0161ant \u012f fail\u0105 release_agent. Prie\u0161 pataisym\u0105 branduolys netikslino, ar procesas, ra\u0161antis keli\u0105 \u012f release_agent, turi teis\u0119 CAP_SYS_ADMIN pradiniame (hosto) namespace. Tai ir yra CWE-862: tr\u016bkstama autorizacijos patikra. I\u0161naudojimo kelias eina per user namespaces. Linux leid\u017eia neprivegilegijuotam procesui sukurti nauj\u0105 user namespace naudojant unshare, kuriame tas procesas gauna CAP_SYS_ADMIN \u2014 ta\u010diau tik to namespace viduje. Toliau procesas prijungia cgroupfs naujame namespace ir \u012f release_agent \u012fra\u0161o keli\u0105 iki bet kokio skripto. Branduolys netikrina, ar CAP_SYS_ADMIN buvo gauta konteinerinio namespace viduje, o ne pradiniame. Kai cgroup i\u0161tu\u0161t\u0117ja \u2014 branduolys paleid\u017eia skript\u0105 kaip root ant hosto. KAIP TAI I\u0160NAUDOJAMA U\u017epuolikas, gav\u0119s shell konteinerio viduje, vykdo toki\u0105 sek\u0105. Sukuriamas naujas user namespace \u2014 neprivegilegijuotas procesas gauna jame CAP_SYS_ADMIN, bet tik to namespace ribose. Prijungiamas cgroupfs, sukuriama antrin\u0117 cgroup, o \u012f \u0161aknin\u0117s cgroup fail\u0105 release_agent \u012fra\u0161omas kelias iki backdoor skripto. \u012ejungiamas notify_on_release sukurtai cgroup, procesas joje baigia darb\u0105 \u2014 cgroup i\u0161tu\u0161t\u0117jo, branduolys i\u0161kvie\u010dia release_agent. Skriptas vykdomas kaip root hosto kontekste, aplenkiant visus konteinerio namespace apribojimus. Svarbu suprasti: norint i\u0161naudoti pa\u017eeid\u017eiamum\u0105 per user namespaces, nereikia b\u016bti root konteinerio viduje. Pakanka neprivegilegijuoto vartotojo \u2014 jei tik hosto sistemoje \u012fjungti user namespaces, o jie \u012fjungti pagal numatytuosius nustatymus Ubuntu, Debian ir daugumoje distribucij\u0173. Root procesui konteinerio viduje \u2014 pavyzd\u017eiui, nginx, veikian\u010diam kaip root \u2014 reikalavimai dar ma\u017eesni. KAS NUTINKA TOLIAU \u2014 PRIKLAUSO NUO KONFIG\u016aRACIJOS Rezultatas priklauso nuo to, kiek hardened j\u016bs\u0173 konteineri\u0173 aplinka. Jei konteineris paleistas su AppArmor, SELinux enforcing re\u017eimu arba Seccomp \u2014 jie blokuoja reikiamus sisteminius i\u0161kvietimus (cgroupfs prijungim\u0105, unshare) dar prie\u0161 tai, kai ataka gali progresuoti. Docker pagal numatytuosius nustatymus taiko seccomp profil\u012f, kuris teori\u0161kai apriboja \u0161ias operacijas \u2014 bet tik jei konteineris nepaleistas su –privileged, –security-opt seccomp=unconfined arba –cap-add SYS_ADMIN. Jei konteineris paleistas be papildom\u0173 apsaugos priemoni\u0173 \u2014 arba su susilpnintais profiliais, kas da\u017enai pasitaiko CI\/CD aplinkose, k\u016brimo aplinkose ir \u201egreituose” diegimuose \u2014 i\u0161naudojimas pavyksta ir baigiasi visu hosto kompromitavimu. Kubernetes aplinkoje u\u017epuolikas, per\u0117m\u0119s vien\u0105 pod ant mazgo su cgroups v1, gali kompromituoti visus kitus to mazgo pod ir jud\u0117ti toliau po klaster\u012f. REALI ATAKOS GRANDIN\u0116 Tipinis \u0161iuo metu i\u0161naudojamas scenarijus: WordPress veikia Docker konteineryje. U\u017epuolikas randa pa\u017eeid\u017eiam\u0105 \u012fskiep\u012f \u2014 RCE arba failo \u012fk\u0117limo pa\u017eeid\u017eiamum\u0105 \u2014 ir gauna shell kaip www-data konteinerio viduje. Hostas veikia Ubuntu 20.04 su branduoliu, kuris neatnaujintas nuo diegimo prie\u0161 dvejus metus. cgroups v1 aktyvus, AppArmor nesukonfig\u016bruotas konteineriams, Seccomp nepatobulintas. Per CVE-2022-0492 u\u017epuolikas per kelias sekundes gauna root ant hosto, nuskaito \/etc\/shadow, \u012fdiegia SSH backdoor ir gauna nuolatin\u0119 prieig\u0105 prie serverio. Konteineris tuo metu toliau veikia \u2014 i\u0161ori\u0161kai niekas nesugedo, joki\u0173 \u012fsp\u0117jim\u0173. CHRONOLOGIJA 2021 m. lapkritis \u2014 Aqua Security Team Nautilus tyr\u0117jai fiksuoja pirm\u0105 real\u0173 container escape technikos per release_agent i\u0161naudojim\u0105 gamtoje. Atkreipkite d\u0117mes\u012f: dar be CVE, dar be pataisymo \u2014 tiesiog tyliai veikiantis eksploitas realiose atakose. 2022 m. vasario 4 d. \u2014 Linux atskleid\u017eia CVE-2022-0492, branduolio versijoje 5.17-rc3 i\u0161leid\u017eiamas pataisymas. 2022 m. kovas \u2014 Ubuntu, Red Hat, Debian i\u0161leid\u017eia atnaujintus branduolius. Ar visi atsinaujino? Ne. 2026 m. bir\u017eelio 2 d. \u2014 CISA \u012ftraukia CVE-2022-0492 \u012f KEV su terminu JAV federalin\u0117ms agent\u016broms bir\u017eelio 5 d. Pra\u0117jo ketveri metai nuo pataisymo. Atakos t\u0119siasi. Tai ne anomalija \u2014 tai standartinis rezultatas nepataisose sistemose. KAIP TAI I\u0160GYVENO 4+ METUS Pa\u017eeid\u017eiamumas egzistavo branduolyje nuo pat user namespaces atsiradimo \u2014 funkcionalumo, prid\u0117to Linux 3.8 versijoje 2013 m. Beveik de\u0161imt met\u0173. I\u0161naudojimo technika per release_agent saugumo bendruomen\u0117je buvo \u017einoma gerokai prie\u0161 2022 m.: 2019 m. liep\u0105 Google Project Zero tyr\u0117jas Felix Wilhelm paskelb\u0117 container escape proof-of-concept, naudojant \u0161i\u0105 funkcij\u0105 prie\u0161 privilegijuotus konteinerius. Visi \u017einojo, kad release_agent vykdomas kaip root. Ta\u010diau buvo manoma: norint ten ra\u0161yti, reikia CAP_SYS_ADMIN hosto namespace. Niekas netikslino, ar kodas tai tikrina. Pataisymas pasirod\u0117 es\u0105s vienos eilut\u0117s. Vienas ns_capable(ns, CAP_SYS_ADMIN) i\u0161kvietimas tinkamoje vietoje \u2014 commit 24f6008564183aa120d07c03d9289519c2fe02af Torvalds repozitorijuje. De\u0161imt met\u0173 pa\u017eeid\u017eiamumo \u2014 viena eilut\u0117 pataisymui. Palo Alto Unit 42 pavadino j\u012f \u201evienu i\u0161 papras\u010diausi\u0173 Linux privilege escalation atradim\u0173 pastaruoju metu” \u2014 ir tai n\u0117ra komplimentas branduolio k\u016br\u0117jams. Tai priminimas, kad patys pavojingiausi klaidai da\u017enai atrodo kaip nuobod\u017eios login\u0117s klaidos. KOD\u0116L TAI VIS DAR AKTUALU CVE patekimas \u012f KEV pra\u0117jus ketveriems metams po pataisymo \u2014 tai signalas apie problemos mast\u0105. Atakos vektorius yra lokalus, ta\u010diau konteineri\u0173 kontekste \u201elokalus” […]<\/p>\n","protected":false},"author":1,"featured_media":20214,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[202,199,155],"tags":[325,266,267,326,268,327,328,288,329],"class_list":["post-20217","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cve-lt","category-linux-lt","category-saugumas","tag-containersecurity","tag-cve","tag-cybersecurity","tag-docker","tag-infosec","tag-kernelsecurity","tag-kubernetes","tag-linux","tag-security"],"jetpack_featured_media_url":"https:\/\/sysadmin.courses\/wp-content\/uploads\/2026\/06\/CVE-2022-0492.webp","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/sysadmin.courses\/lt\/wp-json\/wp\/v2\/posts\/20217","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/sysadmin.courses\/lt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sysadmin.courses\/lt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sysadmin.courses\/lt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/sysadmin.courses\/lt\/wp-json\/wp\/v2\/comments?post=20217"}],"version-history":[{"count":2,"href":"https:\/\/sysadmin.courses\/lt\/wp-json\/wp\/v2\/posts\/20217\/revisions"}],"predecessor-version":[{"id":20221,"href":"https:\/\/sysadmin.courses\/lt\/wp-json\/wp\/v2\/posts\/20217\/revisions\/20221"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/sysadmin.courses\/lt\/wp-json\/wp\/v2\/media\/20214"}],"wp:attachment":[{"href":"https:\/\/sysadmin.courses\/lt\/wp-json\/wp\/v2\/media?parent=20217"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sysadmin.courses\/lt\/wp-json\/wp\/v2\/categories?post=20217"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sysadmin.courses\/lt\/wp-json\/wp\/v2\/tags?post=20217"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}cgroup_release_agent_write<\/code>, esan\u010dioje faile kernel\/cgroup\/cgroup-v1.c<\/code>. CVSS 7.8 (High), CWE-862 (Missing Authorization). J\u012f atrado Yiqi Sun ir Kevin Wang i\u0161 Huawei, atskleidimas \u012fvyko 2022 m. vasar\u012f. Pataisymas i\u0161leistas tuo pa\u010diu metu \u2014 branduolio versijoje 5.17-rc3. Atrodyt\u0173, istorija baig\u0117si prie\u0161 ketverius metus.<\/p>\n\n\n\nrelease_agent<\/code> \u2014 special\u0173 fail\u0105, \u012f kur\u012f administratorius gali \u012fra\u0161yti keli\u0105 iki programos. Branduolys t\u0105 program\u0105 paleid\u017eia automati\u0161kai, kai cgroup tampa tu\u0161\u010dia, t. y. visi procesai joje baig\u0117 darb\u0105. Paleid\u017eia kaip root, u\u017e bet koki\u0173 namespace apribojim\u0173 rib\u0173. Tai teis\u0117ta funkcija automatiniam resurs\u0173 i\u0161valymui. \u012esivaizduokite valytoj\u0105 su universaliu raktu: jis ateina kai visi i\u0161eina ir atlieka savo darb\u0105. Problema \u2014 kas gali palikti jam nurodymus.<\/p>\n\n\n\nrelease_agent<\/code>. Prie\u0161 pataisym\u0105 branduolys netikslino, ar procesas, ra\u0161antis keli\u0105 \u012f release_agent<\/code>, turi teis\u0119 CAP_SYS_ADMIN<\/code> pradiniame (hosto) namespace. Tai ir yra CWE-862: tr\u016bkstama autorizacijos patikra.<\/p>\n\n\n\nunshare<\/code>, kuriame tas procesas gauna CAP_SYS_ADMIN<\/code> \u2014 ta\u010diau tik to namespace viduje. Toliau procesas prijungia cgroupfs naujame namespace ir \u012f release_agent<\/code> \u012fra\u0161o keli\u0105 iki bet kokio skripto. Branduolys netikrina, ar CAP_SYS_ADMIN<\/code> buvo gauta konteinerinio namespace viduje, o ne pradiniame. Kai cgroup i\u0161tu\u0161t\u0117ja \u2014 branduolys paleid\u017eia skript\u0105 kaip root ant hosto.<\/p>\n\n\n\nCAP_SYS_ADMIN<\/code>, bet tik to namespace ribose. Prijungiamas cgroupfs, sukuriama antrin\u0117 cgroup, o \u012f \u0161aknin\u0117s cgroup fail\u0105 release_agent<\/code> \u012fra\u0161omas kelias iki backdoor skripto. \u012ejungiamas notify_on_release<\/code> sukurtai cgroup, procesas joje baigia darb\u0105 \u2014 cgroup i\u0161tu\u0161t\u0117jo, branduolys i\u0161kvie\u010dia release_agent<\/code>. Skriptas vykdomas kaip root hosto kontekste, aplenkiant visus konteinerio namespace apribojimus.<\/p>\n\n\n\n--privileged<\/code>, --security-opt seccomp=unconfined<\/code> arba --cap-add SYS_ADMIN<\/code>.<\/p>\n\n\n\nwww-data<\/code> konteinerio viduje. Hostas veikia Ubuntu 20.04 su branduoliu, kuris neatnaujintas nuo diegimo prie\u0161 dvejus metus. cgroups v1 aktyvus, AppArmor nesukonfig\u016bruotas konteineriams, Seccomp nepatobulintas. Per CVE-2022-0492 u\u017epuolikas per kelias sekundes gauna root ant hosto, nuskaito \/etc\/shadow<\/code>, \u012fdiegia SSH backdoor ir gauna nuolatin\u0119 prieig\u0105 prie serverio. Konteineris tuo metu toliau veikia \u2014 i\u0161ori\u0161kai niekas nesugedo, joki\u0173 \u012fsp\u0117jim\u0173.<\/p>\n\n\n\nrelease_agent<\/code> i\u0161naudojim\u0105 gamtoje. Atkreipkite d\u0117mes\u012f: dar be CVE, dar be pataisymo \u2014 tiesiog tyliai veikiantis eksploitas realiose atakose. 2022 m. vasario 4 d. \u2014 Linux atskleid\u017eia CVE-2022-0492, branduolio versijoje 5.17-rc3 i\u0161leid\u017eiamas pataisymas. 2022 m. kovas \u2014 Ubuntu, Red Hat, Debian i\u0161leid\u017eia atnaujintus branduolius. Ar visi atsinaujino? Ne. 2026 m. bir\u017eelio 2 d. \u2014 CISA \u012ftraukia CVE-2022-0492 \u012f KEV su terminu JAV federalin\u0117ms agent\u016broms bir\u017eelio 5 d. Pra\u0117jo ketveri metai nuo pataisymo. Atakos t\u0119siasi. Tai ne anomalija \u2014 tai standartinis rezultatas nepataisose sistemose.<\/p>\n\n\n\nrelease_agent<\/code> saugumo bendruomen\u0117je buvo \u017einoma gerokai prie\u0161 2022 m.: 2019 m. liep\u0105 Google Project Zero tyr\u0117jas Felix Wilhelm paskelb\u0117 container escape proof-of-concept, naudojant \u0161i\u0105 funkcij\u0105 prie\u0161 privilegijuotus konteinerius. Visi \u017einojo, kad release_agent<\/code> vykdomas kaip root. Ta\u010diau buvo manoma: norint ten ra\u0161yti, reikia CAP_SYS_ADMIN<\/code> hosto namespace. Niekas netikslino, ar kodas tai tikrina.<\/p>\n\n\n\nns_capable(ns, CAP_SYS_ADMIN)<\/code> i\u0161kvietimas tinkamoje vietoje \u2014 commit 24f6008564183aa120d07c03d9289519c2fe02af<\/code> Torvalds repozitorijuje. De\u0161imt met\u0173 pa\u017eeid\u017eiamumo \u2014 viena eilut\u0117 pataisymui. Palo Alto Unit 42 pavadino j\u012f \u201evienu i\u0161 papras\u010diausi\u0173 Linux privilege escalation atradim\u0173 pastaruoju metu” \u2014 ir tai n\u0117ra komplimentas branduolio k\u016br\u0117jams. Tai priminimas, kad patys pavojingiausi klaidai da\u017enai atrodo kaip nuobod\u017eios login\u0117s klaidos.<\/p>\n\n\n\napt upgrade<\/code> ant hosto su paskesniu reboot atliekamas kart\u0105 per metus \u2014 jei apskritai atliekamas. B\u016btent tokios sistemos \u0161iuo metu yra taikinyje.<\/p>\n\n\n\nunattended-upgrades<\/code> \u2014 paketas grei\u010diausiai jau \u012fdiegtas, ta\u010diau saugumo atnaujinimai su automatiniu reboot turi b\u016bti \u012fjungti tiesiogiai:<\/p>\n\n\n\nsudo dpkg-reconfigure -plow unattended-upgrades<\/code><\/pre>\n\n\n\n\/etc\/apt\/apt.conf.d\/50unattended-upgrades<\/code>:<\/p>\n\n\n\nUnattended-Upgrade::Automatic-Reboot \"true\";\nUnattended-Upgrade::Automatic-Reboot-Time \"02:00\";<\/code><\/pre>\n\n\n\ndnf-automatic<\/code>. \u012ediekite paket\u0105 ir \u012fjunkite laikmat\u012f:<\/p>\n\n\n\nsudo dnf install -y dnf-automatic\nsudo systemctl enable --now dnf-automatic.timer<\/code><\/pre>\n\n\n\nrelease_agent<\/code> mechanizmo n\u0117ra, tod\u0117l visa \u0161i atak\u0173 klas\u0117 tiesiog i\u0161nyksta.<\/p>\n\n\n\nuname -r<\/code> parodys \u0161iuo metu veikiant\u012f branduol\u012f. Ubuntu 22.04 LTS (jammy) ir Ubuntu 24.04 LTS (noble) nepaveiktos \u2014 jos i\u0161leistos jau su pataisytais branduoliais. Ubuntu 20.04 LTS (focal) sistemoje pataisymas \u012ftrauktas nuo branduolio 5.4.0-105-generic (2022 m. kovas): jei turite senesn\u012f \u2014 sistema pa\u017eeid\u017eiama. Ubuntu 18.04 LTS (bionic) \u2014 nuo branduolio 4.15.0-173-generic.<\/p>\n\n\n\nuname -r<\/code><\/pre>\n\n\n\ncpu<\/code>, memory<\/code>, devices<\/code>, blkio<\/code> ir t. t. \u2014 kiekvien\u0105 posistemei. cgroups v2 sistemoje \u2014 viening\u0105 hierarchij\u0105: arba vien\u0105 katalog\u0105 unified<\/code>, arba tiesiog failus kaip cgroup.controllers<\/code> \u0161aknin\u0117je direktorijoje. Jei matote v2 \u2014 pa\u017eeid\u017eiamumas netaikomas.<\/p>\n\n\n\nls \/sys\/fs\/cgroup\/<\/code><\/pre>\n\n\n\nsudo apt update && sudo apt upgrade -y\nsudo reboot<\/code><\/pre>\n\n\n\nsudo dnf clean metadata && sudo dnf upgrade -y kernel\nsudo reboot<\/code><\/pre>\n\n\n\nuname -r<\/code> ir \u012fsitikinkite, kad branduolys atnaujintas. Branduolio atnaujinimas be reboot neturi efekto \u2014 senas branduolys toliau veikia atmintyje iki paleidimo i\u0161 naujo.<\/p>\n\n\n\nCVE-2022-0492-Checker<\/code>, prieinamu GitHub platformoje. Jis tikrina, ar konteineris gali prijungti cgroupfs ir ra\u0161yti \u012f release_agent<\/code>, ir pateikia ai\u0161k\u0173 atsakym\u0105: pa\u017eeid\u017eiama ar ne. Jei branduolio atnaujinti laikinai ne\u012fmanoma \u2014 \u012fsitikinkite, kad konteineriai veikia su AppArmor arba SELinux enforcing re\u017eime, ir nenaudoja --privileged<\/code> ar --security-opt seccomp=unconfined<\/code> nustatym\u0173.<\/p>\n\n\n\nuname -r<\/code> + apt upgrade<\/code> + reboot<\/code> \u2014 trys \u017eingsniai, kurie u\u017edaro real\u0173 atakos vektori\u0173.<\/p>\n","protected":false},"excerpt":{"rendered":"