fa poc es va donar a conèixer informació de la vulnerabilitat (CVE-2022-29582) en la implementació de la interfície d'E/S asíncrona io_uring, inclosa al nucli de Linux des de la versió 5.1, que permet que un usuari sense privilegis es converteixi en root al sistema, fins i tot quan executa un exploit d'un contenidor.
Cal esmentar que aquesta vulnerabilitat es va informar fa poc més de 3 mesos (aproximadament a principis de maig d'aquest any), però la informació completa i la divulgació es va donar a conèixer recentment.
Sobre la vulnerabilitat s'esmenta que aquesta es produeix en accedir a un bloc de memòria ja alliberat, es manifesta als kernels de Linux a partir de la branca 5.10.
Sobre la vulnerabilitat CVE-2022-29582
aquesta vulnerabilitat permet poder accedir a la memòria alliberada com a resultat d'una condició de carrera quan es manegen temps d'espera a la funció io_flush_timeouts(), qui suprimiu l'entrada de temps d'espera de la llista i la cancel·la, sense verificar la creació i eliminació del temps despera en aquest punt.
Una descripció general i actualitzada de io_uring ja ha estat proporcionada per altres. Ho expliquen mil vegades millor que nosaltres, per la qual cosa només cobrirem el subsistema de manera més àmplia (consulteu aquest article de Grapl Security i aquest article de Flatt Security per obtenir una excel·lent introducció).
El que és més important, el camp opcode determina quin tipus doperació realitzar. Perquè cada que opcodi ho requereixi, el camp fd especifica el descriptor de fitxer on realitzar l'E/S sol·licitada. Gairebé totes les trucades al sistema d'E/S normals (read, send, etc.) tenen un codi d'operació asíncron equivalent. Cada camp pot assumir diferents rols segons l'operació.
Un cop recuperat del SQ, un SQE es converteix en una representació interna descrita per struct io_kiocb( kernel input/output call back). Aquests objectes es coneixen comunament com a sol·licituds.
struct io_kiocb utilitza com un equivalent a «ready-for-launch» de l'SQE en què es basa, de manera que qualsevol descriptor d'arxiu es resol en struct file*s, s'adjunten les credencials de l'usuari, s'adjunta la personalitat (en quins nuclis s'executarà), etc.
Un cop finalitzada l'operació sol·licitada, s'escriu a la cua de finalització (CQ) una entrada que correspon al SQE. Aquesta entrada s'anomena entrada de cua de finalització (CQE) i conté camps com a codi d'error i un valor de resultat. L'aplicació de l'espai d'usuari pot sondejar el CQ a la recerca de noves entrades per determinar si els SQE enviats s'han acabat de processar i quin va ser el resultat.
Es esmenten que hi ha alguns escenaris sobre els quals és fàcil reemplaçar un objecte sobre la marxa. Però hi ha dos limitants :
- LT' ha de ser assignat i inicialitzat a una finestra de carrera. És a dir, després que l'LT s'allibera però abans d'arribar a un punt a l'LT que ja no s'hi accedeix.
- LT' només pot ser un altre objecte objecte struct io_kiocb. A causa de l'aïllament del munt, on els objectes del munt se separen segons el seu tipus, és massa difícil reassignar-los com un tipus diferent d'objecte dins de la finestra de carrera.
Els investigadors han preparat un exploit funcional que no requereix la inclusió despais de noms didentificador dusuari (espais de noms dusuari) per al seu funcionament i pot proporcionar accés darrel al sistema principal quan un usuari sense privilegis inicia lexploit en un contenidor aïllat.
El nostre exploit apunta a la versió del nucli 5.10.90, la versió que Google estava executant de forma remota en aquell moment. Vam haver d'ajustar el nostre exploit a les especificacions particulars del servidor (4 nuclis Skylake Xeon @ 2.80Ghz, 16GiB RAM), però amb alguns ajustaments, qualsevol màquina que executi un kernel vulnerable hauria de ser explotable
L'exploit també funciona a l'entorn nsjail aïllat en la distribució Google COS (Container Optimized OS) basada en Chromium OS i utilitzada a Google Cloud Platform en màquines virtuals Compute Engine. L'exploit està dissenyat per funcionar amb branques del nucli de 5.10 a 5.12. Per últim val esmentar que el problema va solucionar a l'abril a les actualitzacions 5.10.111, 5.15.34 i 5.17.3.
Finalment si estàs interessat a poder conèixer més sobre la vulnerabilitat, pots consultar la publicació realitzada en el següent enllaç.