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

 ( trey | 2017. február 16., csütörtök - 9:07 )

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.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

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

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.

Nem volt jobb dolguk?

Hál' istennek nem...

Nagyon komoly!

Üdv,
Marci

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

Pont most, amikor már a FreeBSD-ben is majdnem van ASLR?
/OT

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

É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?

Mikrokód frissítés nem játszik bizonyos típusoknál?

Megis hogy gondolod a kijavitasat ?
Mindenutt legyen super gyors , vagy mindenutt legyen a super lassu ?
2. megoldhato, ha az elso megoldhato lenne biztonsag ide vagy oda ki lesz javitva ;-)


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

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."

Nekem is grsec kernel van telepítve a 4.9.9-es, arch-on.
Vajon csak a védelem kicsiny illúziójában élek ezzel? lehet hogy a hekkernek kb 2 másodperccek tovább tart megtörni a rendszert és root hozzáférést szereznie.

Jó lenne, hogyha a grsec előbb utóbb bekerülne a kernel tree-be és nem kéne patchelni.
____________________________________
Ha vita van, számoljanak órajelciklusokat. Egyesével.

:D

--
trey @ gépház

Parázslasz még.

A hülyeséged helyett inkább magyaráznád meg a téma felvetőjének, hogy miért nem lesz része a grsec a mainline kernelnek (ha tudod) :D

--
trey @ gépház

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

Küldj egy levelet az lmkl-re, hátha.

>:)

Egyébként próbálkoznak már vele egy ideje nagy közösségi összefogással az ARM-tól a Google, IBM és Intelen át a Redhatig, a Linux Foundation támogatásával, csak néha a kompetencia hiányában megy a bénázás és a copyright-sértés... ;)

Az ASLR nem a lokális támadások megnehezítésére született és alapvetően nem védelem, hanem obfuszkáció. A sors fintora, hogy pont ezt az átmenetileg kitalált hardeninget kezdték el átvenni mindenhol, mint fontos biztonsági elemet...

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.

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!

A tavalyi hacktivity-n volt rowhammer.js-rol eloadas. Ha jol emlekszem azt hasznaltak ki, hogy a javascript tomb index a tombot tartalmazo virtualis lap cime + offset.

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!

Ures ez a topik turdus nelkul :(