nylig sårbarhedsoplysninger afsløret (CVE-2022-29582) i implementeringen af den asynkrone I/O-grænseflade io_uring, inkluderet i Linux-kernen siden version 5.1, som tillader en uprivilegeret bruger at blive root på systemet, selv når han udfører en containerudnyttelse.
Det er værd at nævne det nævnte sårbarhed blev rapporteret for lidt over 3 måneder siden (ca. begyndelsen af maj i år), men fuldstændig information og offentliggørelse blev først for nylig udgivet.
Vedrørende sårbarhed nævnes det, at dette opstår ved adgang til en hukommelsesblok, der allerede er frigivet, manifesterer sig i Linux-kerner, der starter med 5.10-grenen.
Om sårbarhed CVE-2022-29582
Denne sårbarhed giver adgang til frigjort hukommelse som et resultat af en løbstilstand ved håndtering af timeouts i io_flush_timeouts()-funktionen, some fjerner timeout-indtastningen fra listen og annullerer den uden at bekræfte oprettelsen og sletningen af timeoutet på det tidspunkt.
En opdateret generel beskrivelse af io_uring er allerede blevet leveret af andre. De forklarer det tusind gange bedre end vi gør, så vi vil blot dække delsystemet mere omfattende (se denne Grapl Security-artikel og denne Flatt Security-artikel for en god introduktion).
Hvad er vigtigere, opcode-feltet bestemmer, hvilken type operation der skal udføres. For hver "opcode", der kræver det, specificerer fd-feltet den filbeskrivelse, som den anmodede I/O skal udføres på. Næsten alle normale I/O-systemopkald (læs, sendt, osv.) har en tilsvarende asynkron opkode. Hvert felt kan påtage sig forskellige roller afhængigt af operationen.
Når først den er hentet fra SQ'en, konverteres en SQE til en intern repræsentation beskrevet af struct io_kiocb (kerne input/output call back). Disse objekter er almindeligvis kendt som anmodninger.
struct io_kiocb bruges som en ækvivalent til den SQE "klar-til-lancering", som den er baseret på, hvorved enhver filbeskrivelse opløses til struct-fil*er, brugerlegitimationsoplysninger er vedhæftet, personlighed (hvilke kerner kører) osv. .
Når den anmodede handling er fuldført, skrives den til færdiggørelseskøen (CQ) en post, der svarer til SQE. En sådan post kaldes en fuldførelseskøindgang (CQE) og indeholder felter som en fejlkode og en resultatværdi. Brugerpladsapplikationen kan polle CQ'en for nye poster for at afgøre, om de sendte SQE'er er færdige med at behandle, og hvad deres resultat var.
Det nævnes, at der er nogle scenarier, hvor det er nemt at erstatte et objekt på fremskridtet. Men der er to begrænsninger:
- LT' skal tildeles og initialiseres i et løbsvindue. Det vil sige, efter at LT er frigivet, men før man når et punkt i LT, som der ikke længere er adgang til.
- LT' kan kun være et andet struct io_kiocb objekt. På grund af heap-isolation, hvor objekter i heapen er adskilt efter deres type, er det for svært at omplacere dem som en anden type objekt inden for race-vinduet.
Forskere har forberedt en funktionel udnyttelse som ikke kræver inkludering af bruger-id-navneområder (brugernavneområder) for dets drift og kan give root-adgang til værten, når en uprivilegeret bruger starter udnyttelsen i en isoleret container.
Vores udnyttelse er rettet mod kerneversion 5.10.90, den version Google kørte på det tidspunkt. Vi var nødt til at justere vores udnyttelse til serverens særlige specifikationer (4 Skylake Xeon-kerner @ 2.80Ghz, 16GiB RAM), men med nogle justeringer, skulle enhver maskine, der kører en sårbar kerne, kunne udnyttes.
Udnyttelsen fungerer også i nsjail-miljøet isoleret på Google COS (Container Optimized OS) distribution baseret på Chromium OS og brugt på Google Cloud Platform på Compute Engine virtuelle maskiner. Benyttelsen er designet til at arbejde med kernegrene fra 5.10 til 5.12. Til sidst er det værd at nævne det problemet blev rettet i april i opdateringer 5.10.111, 5.15.34 og 5.17.3.
Endelig, hvis du er interesseret i at vide mere om sårbarheden, kan du konsultere den udarbejdede publikation I det følgende link.