O vulnerabilitate în KVM permite executarea codului în afara sistemului invitat pe procesoarele AMD

Cercetătorii din echipa Google Project Zero au dezvăluit acum câteva zile într-o postare pe blog care au identificat o vulnerabilitate (CVE-2021-29657) în hipervizorul KVM (un hipervizor open source bazat pe Linux care acceptă virtualizarea accelerată hardware pe x86, ARM, PowerPC și S / 390) care vă permite să evitați izolarea sistemului invitat și rulați codul pe partea de mediu gazdă.

Postarea menționează că problema se manifestă de la nucleul Linux 5.10-rc1 la v5.12-rc6, adică acoperă numai nucleele 5.10 și 5.11 (Majoritatea ramurilor stabile ale distribuțiilor nu au fost afectate de problemă.) Problema este prezentă în mecanismul nested_svm_vmrun, implementat utilizând extensia AMD SVM (Secure Virtual Machine) și care permite lansarea imbricată a sistemelor invitate.

În această postare de blog, descriu o vulnerabilitate în codul KVM specific AMD și discut despre modul în care această eroare se poate transforma într-o evadare completă a mașinii virtuale. Din câte știu, aceasta este prima scriere publică a unui breakout KVM guest-to-host care nu se bazează pe erori în componentele spațiului utilizatorului, cum ar fi QEMU.

Bugul discutat a fost atribuit CVE-2021-29657, afectează versiunile kernel v5.10-rc1 până la v5.12-rc6 și a fost reparat la sfârșitul lunii martie 2021. Deoarece bug-ul a devenit exploatabil doar în v5.10 și a fost descoperit aproximativ 5 luni mai târziu, majoritatea implementărilor KVM din lumea reală nu ar trebui să fie afectate. Încă cred că problema este un studiu de caz interesant în munca necesară pentru a construi o evadare stabilă de la oaspete la gazdă împotriva KVM și sper că acest articol poate susține că compromisurile hipervizorului nu sunt doar probleme teoretice.

Cercetătorii menționează că, pentru implementarea corectă a acestei funcționalități, hipervizorul trebuie să intercepteze toate instrucțiunile SVM rulează pe sisteme de oaspeți, imitați-i comportamentul și sincronizați starea cu hardware-ul, ceea ce este o sarcină destul de dificilă.

După analiza implementării KVM propuse, cercetătoriis-a întâlnit o eroare logică care permite conținutul MSR (Înregistrare specifică modelului) gazdei să fie influențat din sistemul de oaspeți, care poate fi folosit pentru a executa cod la nivel de gazdă.

În special, executarea unei operații VMRUN de la un al doilea invitat de nivel imbricat (L2 lansat de la un alt invitat) duce la un al doilea apel către nested_svm_vmrun și corupă structura svm-> nested.hsave, care este suprapusă cu datele de la vmcb din sistemul de oaspeți L2 .

Ca rezultat, apare o situație în care la nivelul oaspeților L2 este posibil să eliberați memorie în structura svm-> nested.msrpm, care stochează bitul MSR, chiar dacă acesta continuă să fie utilizat și să accesați MSR-ul gazdei mediu.

Aceasta înseamnă, de exemplu, că memoria unui musafir poate fi inspectată aruncând memoria alocată procesului său de spațiu de utilizator sau că limitele resurselor pentru timpul și memoria procesorului pot fi ușor aplicate. 

În plus, KVM poate descărca cea mai mare parte a muncii legate de emularea dispozitivului către componenta spațiului utilizatorului.

Problema este prezentă în codul utilizat pe sistemele cu procesoare AMD (modul kvm-amd.ko) și nu apare pe procesoarele Intel.

 În afara câtorva dispozitive sensibile la performanță legate de gestionarea întreruperilor, tot codul complex de nivel scăzut pentru furnizarea accesului pe disc virtual, rețea sau GPU poate fi implementat în spațiul utilizatorului.  

Cercetătorii pe lângă descrierea problemei De asemenea, au pregătit un prototip de lucru al unui exploit care permite rularea unui shell root dintr-un mediu de oaspeți într-un mediu gazdă pe un sistem cu un procesor AMD Epyc 7351P și un kernel Linux 5.10.

Se observă că acesta este primul invitat care găzduiește vulnerabilitatea în hipervizorul KVM în sine, nu este legat de erori în componentele spațiului utilizatorului, cum ar fi QEMU. Remedierea a fost acceptată în kernel la sfârșitul lunii martie.

În cele din urmă dacă sunteți interesat să aflați mai multe despre asta despre notă, puteți verifica detaliile Î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: Miguel Ángel Gatón
  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.