O vulnerabilitate în io_uring a permis unui utilizator fără permisiuni să devină root chiar și în containere

recent informații despre vulnerabilitate dezvăluite (CVE-2022-29582) în implementarea interfeței I/O asincrone io_uring, inclusă în nucleul Linux începând cu versiunea 5.1, care permite unui utilizator neprivilegiat să devină root pe sistem, chiar și atunci când execută un exploit de container.

Merită menționat faptul că vulnerabilitatea menționată a fost raportată cu puțin peste 3 luni în urmă (aproximativ la începutul lunii mai a acestui an), dar informațiile și dezvăluirile complete au fost lansate abia recent.

În ceea ce privește vulnerabilitatea, se menționează că aceasta apare la accesarea unui bloc de memorie deja eliberat, se manifestă în nucleele Linux începând cu ramura 5.10.

Despre vulnerabilitate CVE-2022-29582

Această vulnerabilitate permite accesul la memoria eliberată ca urmare a unei condiții de concurență la gestionarea timeout-urilor în funcția io_flush_timeouts(), caree elimină intrarea timeout din listă și o anulează, fără a verifica crearea și ștergerea timeout-ului în acel moment.

O descriere generală actualizată a io_uring a fost deja furnizată de alții. Ei o explică de o mie de ori mai bine decât noi, așa că vom acoperi subsistemul mai pe larg (vezi acest articol Grapl Security și acest articol Flatt Security pentru o introducere excelentă).

Ce este mai important, câmpul opcode determină ce tip de operație să efectueze. Pentru fiecare „opcode” care îl solicită, câmpul fd specifică descriptorul de fișier pe care să efectueze I/O solicitat. Aproape toate apelurile normale de sistem I/O (citire, trimitere, etc.) au un opcode asincron echivalent. Fiecare câmp poate avea roluri diferite în funcție de operațiune.

Odată preluat din SQ, un SQE este convertit într-o reprezentare internă descrisă de struct io_kiocb( apel invers de intrare/ieșire a nucleului). Aceste obiecte sunt cunoscute în mod obișnuit ca cereri.

struct io_kiocb este folosit ca echivalent cu SQE „gata pentru lansare” pe care se bazează, prin care orice descriptor de fișier este rezolvat în fișiere struct*, acreditările utilizatorului sunt atașate, personalitatea este atașată (în care nucleele vor rula) , etc.

După ce operațiunea solicitată este finalizată, aceasta este scrisă în coada de finalizare (CQ) o intrare care corespunde SQE. O astfel de intrare se numește intrare de coadă de finalizare (CQE) și conține câmpuri precum un cod de eroare și o valoare a rezultatului. Aplicația de spațiu utilizator poate interoga CQ-ul pentru noi intrări pentru a determina dacă SQE-urile trimise s-au terminat de procesat și care a fost rezultatul lor.

Se menționează că există unele scenarii în care este ușor să înlocuiți un obiect asupra progresului. Dar există două limitări:

  • LT' trebuie să fie atribuit și inițializat într-o fereastră de cursă. Adică după eliberarea LT-ului dar înainte de a ajunge la un punct din LT care nu mai este accesat.
  • LT' poate fi doar un alt obiect struct io_kiocb. Datorită izolării heap, unde obiectele din heap sunt separate în funcție de tipul lor, este prea dificil să le reatribuiți ca un alt tip de obiect în fereastra cursei.

Cercetătorii au pregătit un exploit funcțional care nu necesită includerea de spații de nume de identificare a utilizatorului (spații de nume de utilizator) pentru funcționarea sa și poate oferi acces root la gazdă atunci când un utilizator neprivilegiat lansează exploitul într-un container izolat.

Exploita-ul nostru vizează versiunea kernel-ului 5.10.90, versiunea pe care Google rula de la distanță în acel moment. A trebuit să ne adaptăm exploit-ul la specificațiile specifice ale serverului (4 nuclee Skylake Xeon @ 2.80Ghz, 16GiB RAM), dar cu unele modificări, orice mașină care rulează un nucleu vulnerabil ar trebui să fie exploatabilă.

Exploita-ul funcționează și în mediul nsjail izolat pe distribuția Google COS (Container Optimized OS) bazat pe sistemul de operare Chromium și utilizat pe Google Cloud Platform pe mașinile virtuale Compute Engine. Exploita-ul este proiectat să funcționeze cu ramuri de kernel de la 5.10 la 5.12. În sfârșit, merită menționat că problema remediată în aprilie în actualizările 5.10.111, 5.15.34 și 5.17.3.

În fine, dacă sunteți interesat să aflați mai multe despre vulnerabilitate, puteți consulta publicația realizată În următorul link.


Lasă comentariul tău

Adresa ta de email nu va fi publicată. Câmpurile obligatorii sunt marcate cu *

*

*

  1. Responsabil pentru date: AB Internet Networks 2008 SL
  2. Scopul datelor: Control SPAM, gestionarea comentariilor.
  3. Legitimare: consimțământul dvs.
  4. Comunicarea datelor: datele nu vor fi comunicate terților decât prin obligație legală.
  5. Stocarea datelor: bază de date găzduită de Occentus Networks (UE)
  6. Drepturi: în orice moment vă puteți limita, recupera și șterge informațiile.