A kutatók szerint megjegyzik, hogy a sérülékenység napvilágra kerülése jelenleg még nem akkora probléma, a sérülékenységet kihasználó kódot, binárist stb. (exploitot) még nem tettek közzé.
Részletek a sérülékenység honlapján.
- A hozzászóláshoz be kell jelentkezni
- 743 megtekintés
Hozzászólások
No logo, but please do use our fun name!
Akkor nem is igazi sérülékenység! 🤨 😂
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
> leak data that are never read by any instruction
ezt csak en nem ertem? hogy kerult oda az adat, ha soha nem hasznaltak?
- A hozzászóláshoz be kell jelentkezni
Talán valami olyasmiről lehet szó, hogy ez a prefetcher tartalmat is figyelembe vesz, s ha ismerjük, a prefetcherben milyen szabályszerűség triggereli a prefetch-et, s azt is ki tudjuk deríteni, hogy a prefetch megtörtént, tehát a prefetcher triggerelődött, akkor a prefetchert software-esen modellezve ki tudjuk kalkulálni, mi lehetett az az adat, ami a triggerelést előidézte. Ekkor nem kell elhozni az adatot, de tudjuk, hogy a hardware működésbe lépéséhez milyen adat kellett, így megvan az adat.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Én is még csak emésztem a cikket, nagyjából eddig ez jött le:
A processzorba beépített DMP (adattartalomfüggő prefetcher) elvileg azt figyeli, hogy
for(i=0; i<Array.length; i++) { do_something_with(*(Array[i])) }
jellegű viselkedés történik-e a program végrehajtása során. Vagyis pointer tömbön halad-e végig a program és az egyes pointerek által hivatkozott adatot beolvassa-e.
Ha észreveszi, hogy igen, akkor elkezd előreszaladni és betöltögeti cache-be egyrészt az Array[n+1]-edik elemét, másrészt az Array[n+1]-en talált adatot memóriacímként értelmezi, és az ott található adatot is betölti.
Mi ezzel a gond?
Az, hogy a prefetcher nem tudja, hogy hol a tömb vége és simán túlolvassa, akár jelentős mértékben is. A tömb után következő adatokat (ami egyáltalán nem is biztos, hogy pointer), szintén pointernek nézi, és akárhova is mutasson, azt beolvassa.
A támadó pedig kiderítheti, hogy honnan olvasott be valamit a cache-be, egyszerűen azzal, hogy megpróbál különféle címekről olvasgatni és méri az időt. Ha valamelyik olvasás gyanúsan gyors volt, akkor lehet tudni, hogy az cache-ben van, mert korábban a prefetcher milyen címről töltött be valamit (*).
(* Valójában ez durva leegyszerűsítése a Prime and Probe technikának. A cache set-asszociativitását használja ki, ezért nem kell végigpróbálnia sokmillió címet, max 1-2000 próbálkozásból megvan. Valójában nem is azt teszteli, hogy ráhibázott-e a címre, mert nincs is feltétlen joga olvasni arról a címről. Arra épít, hogy egy adott set-be tartozó cache sorok telítődése miatt mikor dobódik ki az eredetileg cache-elt adat. Nyilván pontosan ismerni kell hozzá az adott processzor modell cache működését.)
Hogy pontosan mit töltött be, az nem érdekes. Mivel a prefetcher a tömb vége utáni nem-pointer adatokat is címnek nézte, ezért elég a cím.
Egy fontos megkötés ebben, hogy a címek virtuálisak, ez a módszer egy adott process virtuális memóriatartományán belül működik. Ezért alapvetően a sandbox-ok (böngészőben futó javascript és hasonlók) veszélyeztetettek.
A cikk nagy része még olyasmikről szól, hogy a sandboxban futó támadó hogy tudja kirpovokálni, hogy a prefetcher garantáltan ráinduljon olyan címekre is, amikhez neki a sandboxból nem lenne joga hozzáférni.
Régóta vágyok én, az androidok mezonkincsére már!
- A hozzászóláshoz be kell jelentkezni