Ang isang kahinaan sa io_uring ay nagbigay-daan sa isang user na walang pahintulot na maging root kahit sa mga container

Kamakailan lamang inihayag ang impormasyon ng kahinaan (CVE-2022-29582) sa pagpapatupad ng io_uring asynchronous I/O interface, kasama sa Linux kernel mula noong bersyon 5.1, na nagbibigay-daan sa isang walang pribilehiyong user na maging root sa system, kahit na nag-execute ng container exploit.

Ito ay nagkakahalaga ng pagbanggit na ang nasabing kahinaan ay naiulat lamang mahigit 3 buwan ang nakalipas (humigit-kumulang sa unang bahagi ng Mayo ngayong taon), ngunit ang buong impormasyon at pagsisiwalat ay inilabas lamang kamakailan.

Tungkol sa kahinaan, nabanggit na ito nangyayari kapag ina-access ang isang bloke ng memorya na napalaya na, ay nagpapakita ng sarili sa mga kernel ng Linux simula sa 5.10 branch.

Tungkol sa kahinaan sa CVE-2022-29582

Ang kahinaan na ito nagbibigay-daan sa pag-access sa libreng memorya bilang resulta ng kundisyon ng lahi kapag humahawak ng mga timeout sa function na io_flush_timeouts(), nae inaalis ang timeout entry mula sa listahan at kinansela ito, nang hindi bini-verify ang paggawa at pagtanggal ng timeout sa puntong iyon.

Ang isang na-update na pangkalahatang paglalarawan ng io_uring ay naibigay na ng iba. Ipinaliwanag nila ito ng isang libong beses na mas mahusay kaysa sa amin, kaya tatalakayin lang namin ang subsystem nang mas malawak (tingnan ang artikulong ito ng Grapl Security at ang artikulong ito ng Flatt Security para sa isang mahusay na panimula).

Ano ang mas mahalaga, tinutukoy ng field ng opcode kung anong uri ng operasyon ang gagawin. Para sa bawat "opcode" na nangangailangan nito, ang fd field ay tumutukoy sa file descriptor kung saan isasagawa ang hiniling na I/O. Halos lahat ng normal na I/O system call (read, sendto, atbp.) ay may katumbas na asynchronous opcode. Ang bawat field ay maaaring kumuha ng iba't ibang tungkulin depende sa operasyon.

Sa sandaling makuha mula sa SQ, ang isang SQE ay iko-convert sa isang panloob na representasyon na inilarawan ng struct io_kiocb( kernel input/output call back). Ang mga bagay na ito ay karaniwang kilala bilang mga kahilingan.

Ang struct io_kiocb ay ginagamit bilang katumbas ng SQE na "ready-for-launch" kung saan ito nakabatay, kung saan ang anumang file descriptor ay naresolba sa struct file*s, ang mga kredensyal ng user ay nakalakip, personalidad (kung saan tatakbo ang mga core), atbp .

Matapos makumpleto ang hiniling na operasyon, isusulat ito sa queue ng pagkumpleto (CQ) isang entry na tumutugma sa SQE. Ang nasabing entry ay tinatawag na completion queue entry (CQE) at naglalaman ng mga field gaya ng error code at value ng resulta. Maaaring i-poll ng user space application ang CQ para sa mga bagong entry upang matukoy kung ang mga ipinadalang SQE ay tapos na sa pagproseso at kung ano ang kanilang resulta.

Nabanggit na may ilang mga sitwasyon kung saan madaling palitan ang isang bagay sa pag-unlad. Ngunit mayroong dalawang limitasyon:

  • Ang LT' ay kailangang italaga at simulan sa isang window ng karera. Ibig sabihin, pagkatapos mailabas ang LT ngunit bago umabot sa punto sa LT na hindi na naa-access.
  • Ang LT' ay maaari lamang maging isa pang struct io_kiocb object. Dahil sa heap isolation, kung saan ang mga bagay sa heap ay pinaghihiwalay ayon sa kanilang uri, napakahirap na muling italaga ang mga ito bilang ibang uri ng bagay sa loob ng race window.

Naghanda ang mga mananaliksik ng functional exploit na hindi nangangailangan ng pagsasama ng mga namespace ng user identifier (mga namespace ng user) para sa pagpapatakbo nito at maaaring magbigay ng root access sa host kapag inilunsad ng isang walang pribilehiyong user ang pagsasamantala sa isang nakahiwalay na lalagyan.

Ang aming pagsasamantala ay nagta-target ng bersyon ng kernel na 5.10.90, ang bersyon na malayong pinapatakbo ng Google noong panahong iyon. Kinailangan naming ayusin ang aming pagsasamantala sa mga partikular na detalye ng server (4 Skylake Xeon core @ 2.80Ghz, 16GiB RAM), ngunit sa ilang pag-aayos, anumang makina na nagpapatakbo ng mahinang kernel ay dapat na mapagsamantalahan.

Gumagana rin ang pagsasamantala sa kapaligiran ng nsjail nakahiwalay sa pamamahagi ng Google COS (Container Optimized OS) batay sa Chromium OS at ginamit sa Google Cloud Platform sa mga virtual machine ng Compute Engine. Ang pagsasamantala ay idinisenyo upang gumana sa mga sanga ng kernel mula 5.10 hanggang 5.12. Panghuli, ito ay nagkakahalaga ng pagbanggit na naayos ang problema noong Abril sa mga update 5.10.111, 5.15.34 at 5.17.3.

Sa wakas, kung interesado kang malaman ang higit pa tungkol sa kahinaan, maaari kang sumangguni sa ginawang publikasyon Sa sumusunod na link.


Iwanan ang iyong puna

Ang iyong email address ay hindi nai-publish. Mga kinakailangang patlang ay minarkahan ng *

*

*

  1. Responsable para sa data: AB Internet Networks 2008 SL
  2. Layunin ng data: Kontrolin ang SPAM, pamamahala ng komento.
  3. Legitimation: Ang iyong pahintulot
  4. Komunikasyon ng data: Ang data ay hindi maiparating sa mga third party maliban sa ligal na obligasyon.
  5. Imbakan ng data: Ang database na naka-host ng Occentus Networks (EU)
  6. Mga Karapatan: Sa anumang oras maaari mong limitahan, mabawi at tanggalin ang iyong impormasyon.