nyligen sårbarhetsinformation avslöjad (CVE-2022-29582) i implementeringen av det asynkrona I/O-gränssnittet io_uring, inkluderat i Linux-kärnan sedan version 5.1, vilket tillåter en oprivilegierad användare att bli root på systemet, även när en containerexploatör utförs.
Det är värt att nämna det nämnda sårbarhet rapporterades för drygt 3 månader sedan (ungefär början av maj i år), men fullständig information och avslöjande släpptes först nyligen.
Angående sårbarhet nämns att detta inträffar vid åtkomst till ett minnesblock som redan är frigjort, manifesterar sig i Linux-kärnor som börjar med 5.10-grenen.
Om sårbarhet CVE-2022-29582
Denna sårbarhet ger tillgång till frigjort minne som ett resultat av ett tävlingstillstånd vid hantering av timeouts i funktionen io_flush_timeouts(), some tar bort timeout-posten från listan och avbryter den, utan att verifiera skapandet och raderingen av timeouten vid den tidpunkten.
En uppdaterad allmän beskrivning av io_uring har redan tillhandahållits av andra. De förklarar det tusen gånger bättre än vi gör, så vi kommer bara att täcka delsystemet mer utförligt (se den här Grapl Security-artikeln och den här Flatt Security-artikeln för en bra introduktion).
Vad är viktigare, opcode-fältet bestämmer vilken typ av operation som ska utföras. För varje "opcode" som kräver det, anger fd-fältet filbeskrivningen på vilken den begärda I/O ska utföras. Nästan alla vanliga I/O-systemanrop (läs, skickad, etc.) har en likvärdig asynkron opkod. Varje fält kan ta olika roller beroende på verksamheten.
När den väl har hämtats från SQ:n konverteras en SQE till en intern representation som beskrivs av struct io_kiocb (kärninmatning/utmatningsanrop). Dessa objekt kallas vanligtvis förfrågningar.
struct io_kiocb används som en motsvarighet till SQE "ready-for-launch" som den är baserad på, varvid vilken filbeskrivning som helst löses till struct-fil*s, användaruppgifter bifogas, personlighet (i vilken kärnor kommer att köras), etc. .
När den begärda operationen är klar skrivs den till färdigställandekön (CQ) en post som motsvarar SQE. En sådan post kallas en kompletteringsköpost (CQE) och innehåller fält som en felkod och ett resultatvärde. Användarutrymmesapplikationen kan polla CQ för nya poster för att avgöra om de skickade SQE:erna har avslutat bearbetningen och vad deras resultat var.
Det nämns att det finns några scenarier där det är lätt att byta ut ett objekt på framstegen. Men det finns två begränsningar:
- LT' måste tilldelas och initieras i ett tävlingsfönster. Det vill säga efter att LT har släppts men innan man når en punkt i LT som inte längre nås.
- LT' kan bara vara ett annat struct io_kiocb-objekt. På grund av högisolering, där objekt i högen är separerade efter deras typ, är det för svårt att omplacera dem som en annan typ av objekt inom tävlingsfönstret.
Forskare har förberett en funktionell exploatering som inte kräver inkludering av användaridentifierare namnområden (användarnamnområden) för dess drift och kan ge root-åtkomst till värden när en oprivilegierad användare startar exploateringen i en isolerad behållare.
Vårt utnyttjande är inriktat på kärnversion 5.10.90, versionen som Google kördes på distans vid den tiden. Vi var tvungna att anpassa vårt utnyttjande till serverns specifika specifikationer (4 Skylake Xeon-kärnor @ 2.80Ghz, 16GiB RAM), men med lite justeringar borde alla maskiner som kör en sårbar kärna kunna utnyttjas.
Exploateringen fungerar även i nsjail-miljön isolerad på Google COS (Container Optimized OS)-distribution baserad på Chromium OS och används på Google Cloud Platform på virtuella Compute Engine-maskiner. Exploateringen är designad för att fungera med kärngrenar från 5.10 till 5.12. Till sist är det värt att nämna det problemet fixades i april i uppdateringarna 5.10.111, 5.15.34 och 5.17.3.
Slutligen, om du är intresserad av att veta mer om sårbarheten kan du konsultera den gjorda publikationen I följande länk.