Som ni vet är koden som körs i enklaven allvarligt begränsad i sin funktionalitet. Den kan inte ringa systemsamtal. Den kan inte utföra I/O-operationer. Den känner inte till basadressen för värdapplikationens kodsegment. Den kan inte jmp eller ringa värdapplikationskod. Den har ingen aning om adressutrymmesstrukturen som styr värdapplikationen (till exempel vilka sidor som är mappade eller vilken typ av data som finns på dessa sidor). Det kan inte be operativsystemet att mappa en del av värdapplikationens minne till det (till exempel genom /proc/pid/maps). Naiva försök att blint läsa en godtycklig minnesregion i en värdapplikation, för att inte tala om försök att skriva, kommer förr eller senare (mest troligt det förra) att leda till att enklavprogrammet tvingas avslutas. Detta händer när den virtuella adressutrymmesregionen som begärs av enklaven är otillgänglig för värdapplikationen.
Med tanke på sådana hårda realiteter, kommer en virusskribent att kunna använda SGX-enklaver för att uppnå sina skadliga mål?
Baserat på allt ovan är det allmänt accepterat att en enklav endast kan tjäna värdapplikationen och att enklaven inte kan utöva sitt eget initiativ, inklusive skadliga sådana. Det betyder att enklaver inte har något praktiskt värde för virusskrivare. Detta förhastade antagande är en av anledningarna till att SGX-skyddet är asymmetriskt: värdapplikationskod kan inte komma åt enklavminne, medan enklavkod kan läsa och skriva till vilken värdapplikationsminnesadress som helst.
Därför, om skadlig enklavkod kunde göra godtyckliga systemanrop på uppdrag av värdapplikationen, exekvera godtycklig kod på dess vägnar, skanna värdapplikationens minne och hitta missbrukbara ROP-kedjor i det, kan den ta fullständig kontroll över värdapplikationen, i smygläge. Det kan inte bara stjäla och kryptera användarfiler, utan också agera på uppdrag av användaren. Skicka till exempel nätfiske-e-post för hans räkning eller utför DoS-attacker. Utan rädsla för ens de mest moderna skyddsmekanismerna, som att stapla kanariefåglar och adressera sanering.
Vi kommer att visa dig några hack som angripare använder för att övervinna begränsningarna som beskrivs ovan för att dra fördel av SGX för sina egna skadliga syften: ROP-attacker. Antingen för att exekvera godtycklig kod förklädd som en värdapplikationsprocess (liknande process ihålning, som ofta används av skadlig programvara), eller för att dölja en färdig skadlig kod (för att rädda dess skadliga program från förföljelse av antivirus och andra försvarsmekanismer).
Hacka för att undersöka adresser för att se om de kan läsas
Eftersom enklaven inte vet vilka intervall i det virtuella adressutrymmet som är tillgängliga för värdapplikationen, och eftersom enklaven tvingas avslutas när man försöker läsa en otillgänglig adress, ställs angriparen inför uppgiften att hitta ett sätt att fel- skanna tolerant adressutrymmet. Hitta ett sätt att kartlägga tillgängliga virtuella adresser. Skurken löser detta problem genom att missbruka Intels TSX-teknik. Använder en av TSX:s bieffekter: om minnesåtkomstfunktionen är placerad i en TSX-transaktion, dämpas undantag som uppstår från åtkomst av ogiltiga adresser av TSX utan att nå operativsystemet. Om ett försök görs att komma åt en ogiltig minnesadress avbryts endast den aktuella transaktionen, inte hela enklavprogrammet. Den där. TSX tillåter en enklav att säkert komma åt vilken adress som helst från en transaktion - utan risk för kollaps.
Om den angivna adressen är tillgänglig värdapplikation är TSX-transaktionen oftast framgångsrik. I sällsynta fall kan det misslyckas på grund av yttre påverkan som avbrott (som schemaläggarens avbrott), cacheavkastningar eller samtidig modifiering av en minnesplats genom flera processer. I dessa sällsynta fall returnerar TSX en felkod som indikerar att felet är tillfälligt. I dessa fall behöver du bara starta om transaktionen.
Om den angivna adressen är inte tillgänglig värdapplikation undertrycker TSX undantaget som inträffade (OSet meddelas inte) och avbryter transaktionen. En felkod returneras till enklavkoden så att den kan reagera på att transaktionen har avbrutits. Dessa felkoder indikerar att adressen i fråga inte är tillgänglig för värdapplikationen.
Denna manipulation av TSX inifrån enklaven har en trevlig funktion för skurken: eftersom de flesta hårdvaruprestandaräknare inte uppdateras när enklavkoden exekveras, är det omöjligt att spåra TSX-transaktioner som exekveras inne i enklaven. Således förblir skadlig manipulation av TSX helt osynlig för operativsystemet.
Dessutom, eftersom hacket ovan inte är beroende av några systemanrop, kan det varken upptäckas eller förhindras genom att helt enkelt blockera systemanrop; vilket brukar ge ett positivt resultat i kampen mot äggjakten.
Skurken använder hacket som beskrivs ovan för att söka i värdapplikationskoden efter prylar som är lämpliga för att bilda en ROP-kedja. Samtidigt behöver han inte sondera varje adress. Det räcker att undersöka en adress från varje sida i det virtuella adressutrymmet. Att sondera alla 16 gigabyte minne tar cirka 45 minuter (på en Intel i7-6700K). Som ett resultat får skurken en lista med körbara sidor som är lämpliga för att konstruera en ROP-kedja.
Hacka för att undersöka adresser för skrivbarhet
För att utföra en enklavversion av en ROP-attack måste en angripare kunna söka efter skrivbara oanvända minnesområden i värdapplikationen. Angriparen använder dessa minnesplatser för att injicera en falsk stackram och för att injicera en nyttolast (skalkod). Summan av kardemumman är att en skadlig enklav inte kan kräva att värdapplikationen allokerar minne åt sig själv, utan kan istället missbruka minne som redan tilldelats av värdapplikationen. Om han förstås lyckas hitta sådana områden utan att kollapsa enklaven.
Skurken utför denna sökning genom att utnyttja en annan bieffekt av TSX. Först, som i det föregående fallet, undersöker den adressen för dess existens och kontrollerar sedan om sidan som motsvarar denna adress är skrivbar. För att göra detta använder skurken följande hack: han placerar en skrivfunktion i en TSX-transaktion, och efter att den har slutförts, men innan den har slutförts, avbryter han transaktionen med tvång (explicit avbryt).
Genom att titta på returkoden från en TSX-transaktion förstår angriparen om den är skrivbar. Om det är en "uttrycklig abort" förstår skurken att inspelningen skulle ha varit framgångsrik om han hade följt med. Om sidan är skrivskyddad slutar transaktionen med ett annat fel än "explicit avbryt".
Denna manipulation av TSX har en annan funktion som är trevlig för skurken (förutom omöjligheten att spåra genom hårdvaruprestandaräknare): eftersom alla minnesskrivkommandon endast begås om transaktionen lyckas, säkerställer att tvinga transaktionen att slutföras att den undersökta minnescellen förblir oförändrad.
Hacka för att omdirigera kontrollflödet
När man utför en ROP-attack från en enklav - till skillnad från traditionella ROP-attacker - kan angriparen få kontroll över RIP-registret utan att utnyttja några buggar i det attackerade programmet (buffertspill eller liknande). En angripare kan direkt skriva över värdet på RIP-registret som är lagrat i stacken. I synnerhet kan den ersätta värdet på detta register med sin egen ROP-kedja.
Men om ROP-kedjan är lång kan en överskrivning av en stor del av värdapplikationens stack leda till datakorruption och oväntat programbeteende. Skurken, som försöker utföra sin attack i hemlighet, är inte nöjd med detta tillstånd. Därför skapar den en falsk tillfällig stackram för sig själv och lagrar sin ROP-kedja i den. Den falska stapelramen placeras på en slumpmässig skrivbar minnesplats, vilket lämnar den verkliga stapeln intakt.
Vad ger de tre hackarna ovan skurken?
(1) Först den illvilliga enklaven igenom hacka för att undersöka adresser för att se om de kan läsas, – söker i värdapplikationen efter missbrukbara ROP-prylar.
(2) Sedan genom hacka för att undersöka adresser för skrivbarhet, – en skadlig enklav identifierar områden i värdapplikationens minne som är lämpliga för att injicera en nyttolast.
(3) Därefter skapar enklaven en ROP-kedja från prylarna som upptäcktes i steg (1) och injicerar denna kedja i värdapplikationsstacken.
(4) Slutligen, när värdapplikationen stöter på ROP-kedjan som skapades i föregående steg, börjar den skadliga nyttolasten exekvera - med värdapplikationens privilegier och möjligheten att göra systemanrop.
Hur en skurk använder dessa hacks för att skapa ranzowari
Efter att värdapplikationen överför kontrollen till enklaven genom en av ECALL:erna (utan att misstänka att den här enklaven är skadlig), söker den skadliga enklaven efter ledigt utrymme i minnet av värdapplikationen för att injicera kod (tar som lediga utrymmen dessa cellsekvenser som fylls med nollor). Sedan igenom hacka för att undersöka adresser för att se om de kan läsas, – enklaven söker efter körbara sidor i värdapplikationen och genererar en ROP-kedja som skapar en ny fil med namnet "RANSOM" i den aktuella katalogen (i en riktig attack krypterar enklaven befintliga användarfiler) och visar ett lösenmeddelande. Samtidigt tror värdapplikationen naivt att enklaven helt enkelt lägger till två nummer. Hur ser detta ut i koden?
För att underlätta uppfattningen, låt oss introducera några mnemonics genom definitionerna:
Vi sparar de ursprungliga värdena för RSP- och RBP-registren för att återställa normal drift av värdapplikationen efter att ha kört nyttolasten:
Vi letar efter en lämplig stackram (se koden från avsnittet "hack för omdirigering av kontrollflöde").
Hitta lämpliga ROP-prylar:
Hitta en plats att injicera nyttolasten:
Vi bygger en ROP-kedja:
Det är så Intels SGX-teknik, designad för att motverka skadliga program, utnyttjas av skurkar för att uppnå motsatta mål.
Källa: will.com