Új hozzászólás Aktív témák
-
XMI
csendes tag
+ a cache tartalommal címezhető memória - kihasználva következtetni lehet memóriaterületek tartalmára.
Ez a rész nem teljesen pontos. A cache-nek csak egy része, az ún. tag memóriája tartalom szerint címezhető, de ez csak az adott cache line-ban tárolt adat memóriacímét tárolja (annak sem az összes bitjét - a set asszociativitás részleteibe most nem megyek bele), magát az adatot nem. A tényleges adat a cache line-ban van, ennek tartalmára (olvasási jogosultság nélkül) nem lehet következtetni, csak arra, hogy benn van-e vagy sem. A mostani támadások során valójában mindig csak a benn van/nincs benn számít, a tényleges adattartalom lényegtelen.de kihasználni nehéz,ha nincs más sebezhetőség.
Nem, sajnos ezt nagyon triviális kihasználni, és ez egyáltalán nem újdonság. Csak két összejátszó szereplő kell hozzá. Az egyik - a szivárogtató - neki van joga ill. lehetősége beolvasni a szivárogtatni kívánt adatot, annak veszi a soron következő bitjét és vagy olvas egy előre meghatározott memóriacímről vagy nem. A másik - megfigyelő - félnek csak a második memóriacímet van joga olvasni, kiméri az olvasás idejét, ha gyors volt, akkor a szivárogtató fél 1-est küldött, ha lassú, akkor 0-t. Ezzel 1 bitet kiszivárgott úgy, hogy senki nem végzett írásműveletet.Miért releváns ez: mert ha kiderült egy spekulatív végrehajtási ágról, hogy a kezdeti elágazási feltétele tévesen becsült volt, akkor az általa végzett írásműveletek eredményét törli a processzor (pontosabban egyáltalán nem is írja vissza), hiszen az egész logikailag "meg sem történt". Az olvasás műveleteknek nincs logikai hatása, azokon elvileg nincs mit törölni... kivéve az ilyen mellékhatásokat, mint a cache időzítés - és a NetSpectre esetén újdonságként - az egyes végrehajtóegységek power management állapotait. Az írás nélküli szivárogtatási technika lehetővé teszi, hogy a visszatörölt spekulatív végrehajtási ágak kommunikáljanak a külvilág felé. A te leírásodban annyi a ponttalanság, hogy "mivel a spekulatív ág nem törli maga után a regisztereket" - de igen törli.
Ami nem teljesen helyes a második felének leírásában, hogy a Meltdown esetén az Intelnél is dobna exception-t a az első - jogosulatlan - memóriaolvasás hatására, csak túl későn. A végrehajtás előredolgozik annyira, hogy a második - szivárogtató - olvasás is végre tudjon hajtódni és ez éppen elég. De ez valószínűleg orvosolható lesz jövőbeli processzorokban.
Az eredeti Spectre sebezhetőségek abból a szempontból kellemetlenebbek, hogy ott az első olvasás nem jogosulatlan, mert egy olyan folyamat szivárogtat - akaratlanul - ami rendszer normális, biztonsági szempontból jól megírt programkódjának része, nem a támadó kódja. A támadó csak olyan hibás bemenő adatokat ad neki, amit a hibakezelési elágazások amúgy megfognak, de mielőtt ez megtörténik, a processzor spekulatívan előreszaladt és megnézte "mi lett volna", ha nem fogta volna meg a hibakezelés. Ügyesen megválasztott szivárogtató "gadget" kódrészlet esetén marad valami megfigyelhető mellékhatás, amit a támadó által írt megfigyelő kód ki tud deríteni.
A NetSpectre még egyel tovább megy. Itt már sem a szivárogtató, sem a megfigyelő folyamatnak nem kell a támadó kódjának lennie. A támadó az oprendszer hálózati stackjében keres olyan részeket, amik - megfelelően formázott hibás csomagokkal etetve - finom válaszidő-eltérésekkel elárulják 1-1 bit értékét. Nyilván a kiolvasni kívánt memóriacímet a hibás hálózati csomagba kell valahogy belekódolni, hogy pontosan hova és milyen formában, az függ attól, hogy melyik protokoll-mező feldolgozó kódrészletet tudja a támadó kihasználni szivárogtatónak.
Új hozzászólás Aktív témák
ph A NetSpectre által már nem kell helyileg futtatni a támadást biztosító kódot, ami rémisztő, de van örömhír is.
