onlangs kwetsbaarheidsinformatie bekendgemaakt (CVE-2022-29582) in de implementatie van de io_uring asynchrone I/O-interface, opgenomen in de Linux-kernel sinds versie 5.1, waarmee een onbevoegde gebruiker root op het systeem kan worden, zelfs bij het uitvoeren van een container-exploit.
Dat is het vermelden waard genoemde kwetsbaarheid werd iets meer dan 3 maanden geleden gemeld (ongeveer begin mei van dit jaar), maar volledige informatie en openbaarmaking is pas onlangs vrijgegeven.
Met betrekking tot kwetsbaarheid wordt vermeld dat dit: treedt op bij toegang tot een geheugenblok dat al is vrijgemaakt, manifesteert zich in Linux-kernels beginnend met de tak 5.10.
Over kwetsbaarheid CVE-2022-29582
Deze kwetsbaarheid geeft toegang tot vrijgemaakt geheugen als gevolg van een race-conditie bij het afhandelen van time-outs in de io_flush_timeouts() functie, diee verwijdert de time-outinvoer uit de lijst en annuleert deze, zonder de aanmaak en verwijdering van de time-out op dat moment te verifiëren.
Een bijgewerkte algemene beschrijving van io_uring is al door anderen verstrekt. Ze leggen het duizend keer beter uit dan wij, dus we zullen het subsysteem alleen wat uitgebreider behandelen (zie dit Grapl Security-artikel en dit Flatt Security-artikel voor een geweldige introductie).
Wat is belangrijker, het veld opcode bepaalt welk type bewerking moet worden uitgevoerd. Voor elke "opcode" die dit vereist, specificeert het fd-veld de bestandsdescriptor waarop de gevraagde I/O moet worden uitgevoerd. Bijna alle normale I/O-systeemaanroepen (read, sendto, etc.) hebben een equivalente asynchrone opcode. Elk veld kan verschillende rollen aannemen, afhankelijk van de operatie.
Eenmaal opgehaald uit de SQ, wordt een SQE geconverteerd naar een interne representatie beschreven door struct io_kiocb( kernel input/output call back). Deze objecten zijn algemeen bekend als verzoeken.
struct io_kiocb wordt gebruikt als een equivalent van de SQE "ready-for-launch" waarop het is gebaseerd, waarbij elke bestandsdescriptor wordt omgezet in struct file*s, gebruikersreferenties zijn bijgevoegd, persoonlijkheid (waarin kernen worden uitgevoerd), enz. .
Nadat de gevraagde bewerking is voltooid, wordt deze naar de voltooiingswachtrij geschreven (CQ) een invoer die overeenkomt met de SQE. Een dergelijke invoer wordt een voltooiingswachtrijinvoer (CQE) genoemd en bevat velden zoals een foutcode en een resultaatwaarde. De gebruikersruimtetoepassing kan de CQ opvragen voor nieuwe invoer om te bepalen of de verzonden SQE's zijn verwerkt en wat hun resultaat was.
Er wordt vermeld dat er zijn enkele scenario's waarin het gemakkelijk is om een object te vervangen op de voortgang. Maar er zijn twee beperkingen:
- LT' moet worden toegewezen en geïnitialiseerd in een racevenster. Dat wil zeggen, nadat de LT is losgelaten, maar voordat een punt in de LT is bereikt dat niet langer toegankelijk is.
- LT' kan alleen een ander struct io_kiocb-object zijn. Vanwege heap-isolatie, waarbij objecten in de heap worden gescheiden op basis van hun type, is het te moeilijk om ze opnieuw toe te wijzen als een ander type object binnen het racevenster.
Onderzoekers hebben een functionele exploit voorbereid waarvoor geen gebruikersidentificatienaamruimten (gebruikersnaamruimten) nodig zijn voor zijn werking en die roottoegang tot de host kan bieden wanneer een onbevoegde gebruiker de exploit in een geïsoleerde container start.
Onze exploit is gericht op kernelversie 5.10.90, de versie die Google op dat moment op afstand draaide. We moesten onze exploit aanpassen aan de specifieke specificaties van de server (4 Skylake Xeon-cores @ 2.80Ghz, 16GiB RAM), maar met wat aanpassingen zou elke machine met een kwetsbare kernel exploiteerbaar moeten zijn.
De exploit werkt ook in de nsjail-omgeving geïsoleerd op Google COS-distributie (Container Optimized OS) op basis van Chromium OS en gebruikt op Google Cloud Platform op virtuele Compute Engine-machines. De exploit is ontworpen om te werken met kernel-takken van 5.10 tot 5.12. Tot slot is het vermeldenswaard dat het probleem is in april opgelost in updates 5.10.111, 5.15.34 en 5.17.3.
Als u ten slotte meer wilt weten over de kwetsbaarheid, kunt u de gemaakte publicatie raadplegen In de volgende link.