AnC - hatékony támadás az ASLR ellen

Titkosítás, biztonság, privát szféra

A holland Vrije University öt kutatója egy olyan támadást fejlesztett ki, amely rendkívül hatékonynak bizonyul az Address Space Layout Randomization (ASLR) védelmi mechanizmus áthágásában minimum 22 processzorarchitektúrán, beleértve a legnépszerűbb gyártók - Intel, AMD, ARM, Allwinner, Nvidia - termékeit. A támadást ASLR⊕Cache vagy röviden AnC néven emlegetik.

In this project, we show that the limitations of ASLR is fundamental to how modern processors manage memory and build an attack that can fully derandomize ASLR from JavaScript without relying on any software feature. [...] We are releasing the native version of AnC as a library to reverse engineer page table caches. We are not going to release the JavaScript version of AnC in order to protect Internet users from the AnC attack. However, we predict that any sufficiently advanced adversary can replicate our results in a few weeks with the knowledge from our NDSS’17 paper. [...] We started the disclosure process in coordination with the Dutch National Cyber Security Center (NCSC) in October of 2016 with a disclosure date set to February 15, . This was a challenging process involving many different parties including the processor, browser and OS vendors. Some processor vendors agreed with our findings that ASLR is no longer a viable security defense at least for the browsers. Others did not dispute our findings. From the browser vendors, most found AnC relevant.

Részletek a projekt weboldalán.

( sabe v | 2017. 02. 16., cs – 09:24 )

Hű ez kemény. Kicsit irigylem a kutatókat.

( turul16 v | 2017. 02. 16., cs – 09:56 )

Remelem nem ez lesz az uj urugy arra, hogy miert hianyzik egy-ket MMU -altal hasznalt `cache` leirasa majdhogynem az osszes docbol.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( gee v | 2017. 02. 16., cs – 14:54 )

Kíváncsian várom, akkor merre, hogyan tovább

( krychek | 2017. 02. 16., cs – 15:18 )

És ez most azért jó, mert eddig csak sejteni lehetett, hogy a hekkerek használják ezt a támadást, de most már tudjuk is? És majd milyen jó lesz új processzort venni, amiben már ez a hiba ki van javítva?

( Dwokfur v | 2017. 02. 16., cs – 23:04 )

grsec ez ellen vajon mennyire véd?

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Mert a grsec fejlesztő(i)nek nem célja. Hogy miért az az ő dolguk, kár rajta okoskodni, mert ők a kompetensek ebben a témában, nem az aki azt gondolja magáról.

A nagyképű arroganciád mellőzésével inkább magyaráznád meg a téma felvetőjének, hogy ezt honnan tudom? #SzrKvrTrllBlggr

"Mert a grsec fejlesztő(i)nek nem célja."

De egyeztettél velük erről, mielőtt ezt lenyilatkoztad? CC volt? :D

"A nagyképű arroganciád mellőzésével inkább magyaráznád meg a téma felvetőjének, hogy ezt honnan tudom?"

Őő, talán ez?

"#SzrKvrTrllBlggr"

Nem kell itt kódolgatni, nyugodtan írd le a véleményed. Bátran! ;)

--
trey @ gépház

Igen, ez világos. Innen nézve a puffer túlcsordulás elleni védekezés is csak a sebezhetőségek egy része ellen hatásos. Szerencse, hogy a grsec-ben olyan haladó kezdeményezések is megjelentek, mint a RAP.
Az eredeti poszt küldésekor azon gondolkoztam, hogy a grsec-ben található egyéb védő mechanizmusok mennyire tudják megakadályozni, hogy egy JS-ben írt(!) PoC kód haszontalan mélységbe csökkentse az ASLR entrópiát.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Nincs jelentősége, mert a JS/JIT engine és a böngésző többi iszonyat bonyolult részei mérhetetlen sok lehetőséget adnak arra, hogy a tényleges támadáshoz szükséges offset címet kinyerd. Ez az AnC csak a jéghegy csúcsa. Ha a támadót engeded, hogy a te gépeden futtasson saját kódot (akkor is, ha az nem natív, hanem JS, php, Java, Ruby, Python, whatever), akkor az ASLR nem fog tudni segíteni.

Az ASLR nem a mai Javascriptes, Node.js-es, Dockeres, Cloudos, AppEngines, megbízhatatlan kódokat örömmel lokálisan futtató világra lett kitalálva...

Ahogy RMS mondta: "Cloud Computing is a trap". És ez vonatkozik az összes többi trendi dologra is, amit folyamatosan nyomnak le a torkunkon.

Ha használsz grsecet/PaX-ot jóideje, akkor láthatod, hogy "furamód" pont az RWX lapokat igénylő, TPE-t megkerülő, biztonságot nem garantáló technológiák terjednek nagy iramban. Ha egy Cloud/Web App platformot próbálsz saját hatáskörben futtatni és grsecel védeni, akkor muszáj leszel kikapcsolni az MPROTECT, TPE és RBAC korlátozásokat, különben az appok jórésze nem fog működni (vagy persze megpróbálhatsz iszonyat energiával fixálni minden egyes jogosultsági és programozási hibát, sok szerencsét hozzá). Innentől egy támadó már saját kódot fog tudni futtatni egyszerűen a rendszereden, nem tudsz ellene hatékonyan védekezni.

A világ abba az irányba halad gőzerővel, hogy a biztonságnak csak az illúzióját kapjuk meg.

( XMI | 2017. 02. 17., p – 11:12 )

Nekem a cikk átfutása után egy rész maradt balladai homályban: hogy jutnak virtuális memóriacímekhez javascriptből?
Az teljesen világos, hogy hogyan lehet megállapítani egy címről, hogy cache-ben volt-e, akkor is ha le van rontva az óra felbontása, hogy lehet a cache-t üríttetni stb, de itt még mindig egy javascript array index szintjén vagyunk az interpreter process virtuális címeire lefordítás hiányzik.
---
Régóta vágyok én, az androidok mezonkincsére már!

Megnéztem: https://arxiv.org/pdf/1507.06955v1.pdf érdekes, de ha jól értem ez csak egy 2MB-os blokkon belül a cím alsó 21 bitjét tudja megadni, az offest ezzel a módszerrel kideríthetetlen marad. A rowhammer esetén már ez is elég lehet (bár ha jól értem magát a teljes támadást nem demonstrálták, csak a rowhammer bit flip lehetőséget, és szerintük szükség van memória deduplikációra is, hogy elő tudják készíteni a page table layoutot a tényleges támadásra). De az ASLR ellen szerintem a teljes címet meg kéne valahogy fejteni, és úgy tűnik ez valahogy lehetséges is.
---
Régóta vágyok én, az androidok mezonkincsére már!