După cum știți, codul executat în enclavă este foarte limitat în funcționalitatea sa. Nu poate efectua apeluri de sistem. Nu poate efectua operațiuni I/O. Nu știe adresa de bază a segmentului de cod al aplicației gazdă. Nu poate jmp sau apela codul aplicației gazdă. Nu are idee despre structura spațiului de adrese care guvernează aplicația gazdă (de exemplu, ce pagini sunt mapate sau ce fel de date se află pe acele pagini). Nu poate cere sistemului de operare să mapeze o parte din memoria aplicației gazdă la acesta (de exemplu, prin /proc/pid/maps). Încercările naive de a citi orbește o regiune de memorie arbitrară a aplicației gazdă, ca să nu mai vorbim de încercările de scriere, vor duce mai devreme sau mai târziu (cel mai probabil prima) la terminarea forțată a programului enclavă. Acest lucru se întâmplă ori de câte ori regiunea de spațiu de adrese virtuală solicitată de enclavă este inaccesibilă aplicației gazdă.
Având în vedere realități atât de dure, va putea un scriitor de viruși să folosească enclavele SGX pentru a-și atinge obiectivele rău intenționate?
Pe baza tuturor celor de mai sus, se acceptă în general că o enclavă este capabilă doar să servească aplicația gazdă și că enclava nu își poate exercita propria inițiativă, inclusiv pe cele rău intenționate. Aceasta înseamnă că enclavele nu au nicio valoare practică pentru scriitorii de viruși. Această presupunere grăbită este unul dintre motivele pentru care protecția SGX este asimetrică: codul aplicației gazdă nu poate accesa memoria enclavei, în timp ce codul enclavei poate citi și scrie la orice adresă de memorie a aplicației gazdă.
Prin urmare, dacă codul de enclavă rău intenționat a fost capabil să facă apeluri de sistem arbitrare în numele aplicației gazdă, să execute cod arbitrar în numele acesteia, să scaneze memoria aplicației gazdă și să găsească lanțuri ROP abuzabile în ea, ar putea prelua controlul complet al aplicației gazdă, în mod invizibil. Acesta nu poate doar să fure și să cripteze fișierele utilizatorului, ci și să acționeze în numele utilizatorului. De exemplu, trimiteți e-mailuri de phishing în numele lui sau efectuați atacuri DoS. Fără teamă chiar și de cele mai moderne mecanisme de protecție, cum ar fi stiva canari și adresa de igienizare.
Vă vom arăta câteva hack-uri pe care atacatorii le folosesc pentru a depăși limitările descrise mai sus pentru a profita de SGX în propriile lor scopuri rău intenționate: atacuri ROP. Fie pentru a executa cod arbitrar deghizat ca proces de aplicație gazdă (asemănător procesului de golire, care este adesea folosit de malware), fie pentru a masca un malware gata făcut (pentru a-și salva malware-ul de persecuția de către antivirusuri și alte mecanisme de apărare).
Hack pentru a sonda adrese pentru a vedea dacă pot fi citite
Deoarece enclava nu știe care intervale ale spațiului de adrese virtuale sunt accesibile aplicației gazdă și din moment ce enclava este forțată să se termine atunci când încearcă să citească o adresă inaccesibilă, atacatorul se confruntă cu sarcina de a găsi o modalitate de a da greșelii. scanează cu toleranță spațiul de adrese. Găsiți o modalitate de a mapa adresele virtuale disponibile. Nenorocitul rezolvă această problemă utilizând greșit tehnologia Intel TSX. Utilizează unul dintre efectele secundare ale TSX: dacă funcția de acces la memorie este plasată într-o tranzacție TSX, atunci excepțiile care decurg din accesarea adreselor invalide sunt suprimate de TSX fără a ajunge la sistemul de operare. Dacă se încearcă accesarea unei adrese de memorie nevalidă, numai tranzacția curentă este anulată, nu întregul program enclavă. Acea. TSX permite unei enclave să acceseze în siguranță orice adresă din cadrul unei tranzacții - fără riscul de colaps.
Dacă adresa specificată este disponibilă aplicație gazdă, tranzacția TSX are cel mai adesea succes. În cazuri rare, poate eșua din cauza influențelor externe, cum ar fi întreruperile (cum ar fi întreruperile planificatorului), evacuările cache-ului sau modificarea simultană a unei locații de memorie de către mai multe procese. În aceste cazuri rare, TSX returnează un cod de eroare care indică faptul că defecțiunea este temporară. În aceste cazuri, trebuie doar să reporniți tranzacția.
Dacă adresa specificată nu este disponibilă aplicația gazdă, TSX suprimă excepția care a avut loc (OS nu este notificat) și anulează tranzacția. Un cod de eroare este returnat codului de enclavă, astfel încât acesta să poată reacționa la faptul că tranzacția a fost anulată. Aceste coduri de eroare indică faptul că adresa în cauză nu este disponibilă pentru aplicația gazdă.
Această manipulare a TSX din interiorul enclavei are o caracteristică plăcută pentru răufăcător: deoarece majoritatea contoarelor de performanță hardware nu sunt actualizate în momentul în care codul enclavei este executat, este imposibil să urmăriți tranzacțiile TSX executate în interiorul enclavei. Astfel, manipularea rău intenționată a TSX rămâne complet invizibilă pentru sistemul de operare.
În plus, deoarece hack-ul de mai sus nu se bazează pe niciun apel de sistem, nu poate fi nici detectat, nici prevenit prin simpla blocare a apelurilor de sistem; care de obicei dă un rezultat pozitiv în lupta împotriva vânătorii de ouă.
Nelegiuitul folosește hack-ul descris mai sus pentru a căuta în codul aplicației gazdă gadgeturi potrivite pentru formarea unui lanț ROP. În același timp, nu trebuie să verifice fiecare adresă. Este suficient să sondați o adresă din fiecare pagină a spațiului de adrese virtuale. Verificarea tuturor celor 16 gigaocteți de memorie durează aproximativ 45 de minute (pe un Intel i7-6700K). Drept urmare, răufăcătorul primește o listă de pagini executabile care sunt potrivite pentru construirea unui lanț ROP.
Hack pentru a verifica adresele pentru scriere
Pentru a efectua o versiune de enclavă a unui atac ROP, un atacator trebuie să fie capabil să caute zone de memorie inscriptibile neutilizate ale aplicației gazdă. Atacatorul folosește aceste locații de memorie pentru a injecta un cadru de stivă fals și pentru a injecta o sarcină utilă (shellcode). Concluzia este că o enclavă rău intenționată nu este capabilă să solicite aplicației gazdă să aloce memorie pentru ea însăși, ci poate folosi greșit memoria deja alocată de aplicația gazdă. Dacă, desigur, reușește să găsească astfel de zone fără a prăbuși enclava.
Nelegiuitul efectuează această căutare exploatând un alt efect secundar al TSX. Mai întâi, ca și în cazul precedent, sondează adresa pentru existența ei, apoi verifică dacă pagina corespunzătoare acestei adrese este inscriptabilă. Pentru a face acest lucru, răufăcătorul folosește următorul hack: el plasează o funcție de scriere într-o tranzacție TSX și, după ce aceasta s-a finalizat, dar înainte de a fi finalizată, anulează forțat tranzacția (avort explicit).
Privind codul de returnare dintr-o tranzacție TSX, atacatorul înțelege dacă poate fi scris. Dacă este vorba despre un „avort explicit”, ticălosul înțelege că înregistrarea ar fi avut succes dacă ar fi continuat cu ea. Dacă pagina este numai în citire, atunci tranzacția se încheie cu o altă eroare decât „anulare explicită”.
Această manipulare a TSX are o altă caracteristică care este drăguță pentru răufăcător (pe lângă imposibilitatea urmăririi prin contoare de performanță hardware): deoarece toate comenzile de scriere în memorie sunt comise numai dacă tranzacția are succes, forțarea tranzacției să se finalizeze asigură că memoria sondată celula rămâne neschimbată.
Hack pentru a redirecționa fluxul de control
Atunci când efectuează un atac ROP dintr-o enclavă - spre deosebire de atacurile tradiționale ROP - atacatorul poate câștiga controlul asupra registrului RIP fără a exploata niciun bug în programul atacat (buffer overflow sau ceva de genul acesta). Un atacator poate suprascrie direct valoarea registrului RIP stocat pe stivă. În special, poate înlocui valoarea acestui registru cu propriul lanț POR.
Cu toate acestea, dacă lanțul ROP este lung, atunci suprascrierea unei părți mari din stiva aplicației gazdă poate duce la coruperea datelor și la un comportament neașteptat al programului. Nenorocitul, care încearcă să-și desfășoare atacul pe ascuns, nu este mulțumit de această stare de lucruri. Prin urmare, își creează un cadru de stivă temporar fals și își stochează lanțul ROP în el. Cadrul fals al stivei este plasat într-o locație de memorie care poate fi scrisă aleatoriu, lăsând stiva reală intactă.
Ce îi oferă cele trei hack-uri enumerate mai sus răufăcătorului?
(1) În primul rând, prin enclava rău intenționată hack pentru sondarea adreselor pentru a vedea dacă pot fi citite, – caută în aplicația gazdă gadgeturi ROP abuzabile.
(2) Apoi de hack pentru sondarea adreselor pentru scriere, – o enclavă rău intenționată identifică zonele din memoria aplicației gazdă care sunt potrivite pentru injectarea unei sarcini utile.
(3) Apoi, enclava creează un lanț ROP din gadgeturile descoperite la pasul (1) și injectează acest lanț în stiva de aplicații gazdă.
(4) În cele din urmă, când aplicația gazdă întâlnește lanțul ROP creat în pasul anterior, încărcarea utilă rău intenționată începe să se execute - cu privilegiile aplicației gazdă și capacitatea de a efectua apeluri de sistem.
Cum folosește un răufăcător aceste hack-uri pentru a crea ranzowari
După ce aplicația gazdă transferă controlul către enclavă prin unul dintre ECALL-uri (fără a bănui că această enclavă este rău intenționată), enclava rău intenționată caută spațiu liber în memoria aplicației gazdă pentru injectarea codului (luând ca spații libere acele secvențe de celule care umplut cu zerouri). Apoi prin hack pentru sondarea adreselor pentru a vedea dacă pot fi citite, – enclava caută pagini executabile în aplicația gazdă și generează un lanț ROP care creează un fișier nou numit „RANSOM” în directorul curent (într-un atac real, enclava criptează fișierele utilizator existente) și afișează un mesaj de răscumpărare. În același timp, aplicația gazdă crede în mod naiv că enclava adaugă pur și simplu două numere. Cum arată asta în cod?
Pentru ușurința percepției, să introducem câteva mnemonice prin definiții:
Salvăm valorile originale ale registrelor RSP și RBP pentru a restabili funcționarea normală a aplicației gazdă după executarea sarcinii utile:
Căutăm un cadru de stivă potrivit (vezi codul din secțiunea „Hack pentru redirecționarea fluxului de control”).
Găsirea gadgeturilor ROP adecvate:
Găsirea unui loc pentru a injecta sarcina utilă:
Construim un lanț POR:
Acesta este modul în care tehnologia Intel SGX, concepută pentru a contracara programele rău intenționate, este exploatată de răufăcători pentru a atinge obiective opuse.
Sursa: www.habr.com