Új hozzászólás Aktív témák

• #27 XMI csendes tag Tentalus #20

  Új Válasz 2018-08-02 11:51:04 #27

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  XMI

  csendes tag

  válasz Tentalus #20 üzenetére

  A jelszó ennyire nyíltan nincs a memóriában,csak egy hash érték (128 bit).
  Már amikor. Ne tudd meg, hány olyan trehányul kódolt alkalmazás van szerver-oldalon, ahol nem figyelnek ilyesmire. A kliens oldal még nehezebb ott általában elvileg sem tudod elkerülni, hogy átmenetileg a plaintext jelszó memóriában legyen. Legfeljebb annyit lehet (és kellene is) tenni, hogy amilyen hamar csak lehetséges, felülírja a kérdéses memóriaterületet. És akkor jönnek a menedzselt-memóriás, és immutable-változós programnyelvek, ahol hiába írod felül a string változó értékét, újat allokál helyette a régit meg kitakarítja a garbage collector... majd valamikor... (Igen, némelyik programnyelvre lehet találni - sokszor nyakatekert - secure wiping megoldást, némelyikre egyáltalán nincs)

• #28 XMI csendes tag tibaimp #24

  Új Válasz 2018-08-02 12:18:21 #28

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  XMI

  csendes tag

  válasz tibaimp #24 üzenetére

  aki esetleg valamennyire érti is ezt az Intel féle sebezhetőségi dolgot, mert ÉN nem értem:

  Az első amit meg kell érteni, hogy ez nem Intel-féle sebezhetőség. Egyedül a Meltdown volt Intel-specifikus, a Spectre variánsok egy általános processzor sebességoptimalizálási-elvre építenek, amit manapság már kb csak a beágyazott mikrokontrollerekben nem használnak.

  hogy-hogy a világ még működik/ működött az elmúlt 20 évben

  Úgy, hogy egész tavaly nyárig nem jött rá senki, hogy lehet ezt az elvet praktikus támadásban felhasználni. Akadémiai szinten egyébként már régen publikálták, hogy a spekulatív végrehajtás elméletileg akár biztonsági kockázat is lehet, csak 100 ilyen elméleti lehetőségből mondjuk 5-6 olyan van, amire valaha sikerült praktikusan működő támadási technikát kitalálni. Hát erre most sikerült és most azt látjuk, hogy az eredeti Spectre elveit felhasználva találnak ki különféle módszereket, amik különböző környezetben teszik kihasználhatóvá.

  Egyébként jelenleg az a szerencse, hogy a Spectre eddig ismert formáiban még mindig a kifejezetten nehezen kivitelezhető támadások körébe tartozik. De egyrészt fejlődnek az eszközök (ami a programozónak segít azonosítani a támadható programrészeket, az a támadónak is) és sajnos benne van a pakliban, hogy bármikor előáll (*) valaki egy újfajta variánssal, ami kb a Meltdown-hoz hasonló egyszerűséggel használható ki.

  (* Jó esetben előáll. Itt most kb versenyfutás van a white-hat kutatók és a black-hatek között.)

• #31 XMI csendes tag Tentalus #30

  Új Válasz 2018-08-02 20:03:58 #31

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  XMI

  csendes tag

  válasz Tentalus #30 üzenetére

  + 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