Meltdown este o vulnerabilitate hardware de scurgere a canalului lateral găsită într-un număr de microprocesoare, în special cele fabricate de Intel și arhitectura ARM . Meltdown folosește o eroare speculativă de implementare a execuției comenziipe unele procesoare Intel și ARM (dar nu și AMD [1] [2] ), ceea ce face ca procesorul să ignore permisiunile de pagină atunci când execută în mod speculativ instrucțiuni de citire a memoriei.
Vulnerabilitatea permite unui atacator local (când lansează un program special) să obțină acces neautorizat de citire la memoria privilegiată ( memoria utilizată de nucleul sistemului de operare). [3] [4] [5] .
Atacului i s-a atribuit ID-ul de vulnerabilitate CVE CVE-2017-5754 [6] .
Atacul Meltdown a fost descoperit în mod independent de cercetătorii de la Google Project Zero , Cyberus Technology și Graz University of Technology la jumătatea anului 2017 și a fost în discuție închisă și corecții de câteva luni. Publicarea detaliilor și remedierilor a fost programată pentru 9 ianuarie 2018, dar detaliile vulnerabilității au fost făcute publice pe 4 ianuarie 2018, în același timp cu atacul Spectre , datorită publicațiilor jurnaliştilor The Register [7] care au aflat despre corecțiile KAISER/KPTI din lista de corespondență a nucleului Linux [8] .
Capacitatea de a ataca este generată de trei mecanisme care vă permit să accelerați procesorul, iar fiecare dintre aceste mecanisme individual nu creează o vulnerabilitate:
Microprocesoarele moderne de înaltă performanță au capacitatea de a executa cod nou fără a aștepta finalizarea acțiunilor anterioare. De exemplu, dacă o instrucțiune de ramificare așteaptă să primească date din memoria principală pentru a lua o decizie, un procesor inactiv poate fi ocupat cu executarea uneia dintre direcțiile ramificației (și în unele arhitecturi, chiar și ambele ramuri) în speranța de a avea rezultatul calculul gata până în momentul în care rezultatul ramurii este cunoscut. Această tehnică se numește execuție speculativă. Dacă presupunerea are succes, codul executat în mod speculativ modifică valorile vizibile ale registrelor (starea arhitecturală) și execuția continuă. Dacă ramura de execuție a fost asumată incorect, instrucțiunile de la aceasta nu schimbă starea vizibilă a procesorului, iar execuția reală va reveni la punctul de ramificare.
Datorită particularităților unor implementări, în timpul execuției speculative, accesul la memorie se realizează de fapt indiferent de drepturile de acces ale procesului de execuție la această memorie; aceasta permite executarea comenzilor fără a aștepta un răspuns din partea controlerului de memorie . Dacă această ramură a execuției speculative se dovedește mai târziu a fi corectă, atunci va fi aruncată o excepție de acces la memorie eronată. Dacă ramura este aruncată ca fiind eronată, atunci nu va fi aruncată nicio excepție; dar variabilele încărcate în cache în timpul execuției ramurilor vor rămâne în cache. În consecință, autorii atacului au propus o metodă de analiză a prezenței datelor în cache (pe baza timpului de acces la acestea), care, dacă atacul este construit corect, poate da o idee despre ceea ce s-a întâmplat în cazul aruncat. ramura de execuție speculativă și conținutul memoriei mai privilegiate.
Atacul poate fi efectuat aproximativ după cum urmează. [9]
Pentru a citi bitul 0 din zona de memorie protejată A p , atacatorul:
În timpul execuției normale, pasul 4 provoacă o eroare de securitate, dar în timpul execuției speculative pe arhitecturi vulnerabile, această eroare este temporar ignorată, continuând cu pașii 5 și 6. Ca urmare, una dintre valori este încărcată în cache - din adresa A0 u sau A1 u . După ce a aflat starea de ramificare, procesorul anulează toate rezultatele pașilor 4, 5 și 6, dar starea cache-ului rămâne neschimbată.
După aceea, este suficient ca atacatorul să citească adresele „lor” A0 u și A1 u , măsurând timpul de acces la acestea. Și pe baza măsurătorilor, determinați ce bit (0 sau 1) a fost citit din zona de memorie protejată A p .
Repetând acest algoritm pentru alți biți ai valorii V(A p ), puteți obține întregul conținut al zonei de memorie protejată ca întreg.
Potrivit cercetătorilor, „orice microprocesor Intel care implementează execuția necorespunzătoare este potențial susceptibil la atac, adică orice procesor din 1995 (cu excepția Intel Itanium și Intel Atom lansate înainte de 2013)”. [zece]
Vulnerabilitatea este de așteptat să afecteze cei mai mari furnizori de cloud din lume , în special, Amazon Web Services (AWS) [11] , Google Cloud Platform , Microsoft Azure . Furnizorii de cloud permit diferiților utilizatori să își ruleze aplicațiile pe servere fizice partajate. Deoarece programele pot procesa date sensibile ale utilizatorului, măsurile de securitate și izolare furnizate de procesor sunt folosite pentru a preveni accesul neautorizat la memoria privilegiată (utilizată de nucleul sistemului de operare). Atacul Meltdown, atunci când este utilizat pe sisteme care nu implementează protecție software (patch-uri), vă permite să ocoliți unele măsuri de izolare a memoriei și să obțineți acces la citire la memoria sistemului de operare.
Unul dintre autorii publicației de vulnerabilitate indică faptul că sistemele de paravirtualizare ( Xen ) și sistemele container ( Docker , LXC , Openvz etc.) sunt, de asemenea, susceptibile la atac [12] . Sistemele complet virtualizate permit aplicațiilor utilizatorului să citească doar memoria nucleului oaspete, nu memoria sistemului gazdă.
Există o modalitate software fiabilă de a combate atacul, în care tabelul de pagini al proceselor utilizatorului nu afișează paginile de memorie a nucleului de sistem de operare (cu excepția unui număr mic de zone de servicii de memorie a nucleului), tehnologia de izolare a tabelului de pagini kernel (KPTI) . În același timp, apelurile cu o modificare a nivelului de privilegii (în special, apelurile de sistem) încetinesc oarecum, deoarece trebuie să treacă suplimentar la un alt tabel de pagini care descrie întreaga memorie a nucleului OS.
În unele cazuri, remedierea poate reduce performanța anumitor funcții, cum ar fi aplicațiile care efectuează apeluri de sistem foarte frecvent. În același timp, testele Phoronix nu arată nicio încetinire a jocurilor care rulează pe Linux cu patch-ul KPTI [17] [18] .