Új hozzászólás Aktív témák
-
Tyrel
őstag
Milyen hálózati kérésekre való válaszidőről van szó? Mármint mik azok a kérések, elkezdik pingelni vagy mi a szösz?
És a válaszidő méréséből mégis hogy a f...ba lehet visszakövetkeztetni hogy a gép memóriájában mi van, pláne hogy annak tartalma ált. elég gyorsan változik...
És ha a hálózati válaszidőből tényleg visszakóvetkeztethető a memória tartalma, elárulná valaki hogy ez pl. interneten ahol alapvetően ingadozik valamennyit a válaszidőd minden célpont felé, ott mégis hogyan működik ez az egész?...Nem mintha az intel-t akarnám védeni de így első körben nekem ez orbitális bullshitnek tűnik, mi az hogy a hálózati válaszidő alapján memória tartalmat olvasunk, pláne távolról egy véletlenszerűen ingadozó terhelésű hálózaton... meg mi az hogy csak úgy küldözgeted a csomagokat? Erre az első pár másodperc után azt fogja mondani még a tesco gazdaságos router tűzfala is hogy "flooding"-olsz és menj 'nyádba...
Turenkarn
-
bvamosi
csendes tag
Csak laborban mukodik. Amiket írsz az mind igaz es a ddos protection eleg ellenne. De ettol fuggettlenul fel lehet hasznalni bizonyos korulmenyek kozott. https://www.google.de/url?sa=t&source=web&rct=j&url=https://misc0110.net/web/files/netspectre.pdf&ved=2ahUKEwigtuzEyMzcAhWFiKYKHWEHDo0QFjAaegQIARAB&usg=AOvVaw1qilvVQxMigNNXykZlDhek
-
Tyrel
őstag
"Csak laborban mukodik."
Nem mintha nem tennék magasról rá hogy az Intel-t hogyan osztják mert bőven adtak rá okot az utóbbi időben, kijár nekik, de egy szakmai portálon azért ilyen jelentős részleteket illene nem kifelejteni a cikkből... már kivéve persze ha épp pánikkeltés volt a cél, de könyörgöm ne süllyedjünk már le a kormány-média színvonalára...
Turenkarn
-
exedoc
senior tag
Heti Spectre híreinket láthatták.
-
Eclips21
őstag
Volt olyan kutatas is regen hogy a tranzisztorok "zummogesebol" fejtettek vissza azt hogy min dolgozik a processzor
Mindennek van ertelme es haszna csak nyilvan ennel konvergal a nullahoz
-
jacint78
addikt
Nem gondolod komolyan, hogy a net válaszidejét méri ugye? Nem vagyok szakértő, de szerintem a ram és, vagy többi PC komponens válaszidejét mérik. Lehet, hogy a nullának és az egynek más a válaszideje például ramból való kiolvasáskor, vagy ilyesmi inkább.
[ Szerkesztve ]
type your text here..
-
Tyrel
őstag
-
jacint78
addikt
-
rii
nagyúr
ezellen a támadás ellen véd a napi 1x power off .... otthoni felhsználás esetében persze ...
piros-kapszula: https://www.youtube.com/watch?v=oW-VZVYohRg
-
rumkola
veterán
Engem SOKKOLT.
A cím. -
Carlos Padre
veterán
:>
Itt a válasz a sok fanboynak.
Genyó vagyok, ha hülye vagy megmondom.
-
Tentalus
tag
Végigolvastam a bvamosi kolléga által belinkelt eredeti cikket és abból az jön ki,hogy igenis működik a dolog.
Sőt,a cikk szerint (szimulált) terhelés alatt még jobban,mint tiszta,terheletlen hálózatonA módszer lényege az, hogy hálózati kérések teljesítési idejének mérésének sorozatával (kb.1 millió mérés kell,ezért ilyen lassú a módszer) kiolvasható 1 bit. (Ennyi próba esetén a hálózati késleletetés zajából kimérhető a pici memória késleltés ideje). Ez semminek tűnik,de egy root password-höz elég 128 bit.
Ha van AVX2 utasításkészlet a prociban - márpedig Haswell-től van - akkor kevesebb kérés is elég. A trükk itt annyi,hogy az AVX2 kikapcsol 1ms után,ha nem használják és kb 350órajel,mire bekapcsol így szignifkáns a különbség 2 AVX2 utasítás végrehajtási ideje között,ha egymás után vagy 1ms különbséggel hajtják végre.A veszélyeztetett célközönség nyilván az adatközpontokban elhelyezett szerverek,ott nem probléma 1 hetet vármi egy admin password-ra
-
Tentalus
tag
A jelszó ennyire nyíltan nincs a memóriában,csak egy hash érték (128 bit).
A lényeg,hogy a jelszó helye a memóriában adott (az adott operációs rendszert persze ismerni kell hozzá) és kiolvasható. Lehet,hogy egy kicsit sportolni kell előtte,hogy meghatározzam a memóriacímet - egy adott memóriacím mondja meg hol van a password tábla a memóriában- ,de ez a lényeget nem érinti. -
tibaimp
nagyúr
Árulja már el nekem valaki, aki esetleg valamennyire érti is ezt az Intel féle sebezhetőségi dolgot, mert ÉN nem értem:
Ha ez annyira sebezhetővé teszi az Intel alapú PC-ket, akkor a Xeon-al szerelt szervereket is, hogy-hogy a világ még működik/ működött az elmúlt 20 évben és nem rabolták ki az összes bankot, ipari céget, számtek céget....stb, mivel a szervereik ~90%-a Intel alapú????
A tehén egy bonyolult állat, de ÉN megfejtem...| 2016-tól az tuti, hogy az angyalok is esznek babot...
-
Zed895
csendes újonc
"le a kormány-média színvonalára..." -te ugye tortenelembol nem erettsegiztel? Hany eves vagy? Majd ha kicsit idosebb leszel akkor rajosz majd, hogy a mostani media 100x szabadabb mint az elvtarsak idejen volt, vagy mint ami sok masik europai allamban van. Amugy meg vidd innen a gyulolkodo, uszito kommentjeidet, ez egy IT szakmai forum lenne!
[ Szerkesztve ]
Debian 9,5
-
Tentalus
tag
Ezer más sebezhetőség is van,amely nem Intel processzor alapú - általában szoftveres alapúak -némelyiket azért ki is használják,használták,ezek nagy részéről nem is tudunk.
A Spectre,Meltdown hibában az a ritka,hogy hardveres alapú,ezért a szokásosnál nehezebben javítható biztonsági frissítéssel ÉS a javítás egy kicsit lassítja a processzort. -
XMI
csendes tag
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) -
XMI
csendes tag
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.)
-
A hálózati kommunikációt lehet lassítani mesterségesen is, hogy ne legyen annyira "zajos". Pl. egy SYN scan zajos, ha nekiesel a portoknak, de ha szünetet iktatsz be és megfejeled MAC-váltásokkal, nehezebben fogja kiszúrni a router/tűzfal, hogy mindegyik request ugyanonnan jön.
https://www.coreinfinity.tech
-
Tentalus
tag
Üdv
Két dolog keveredik itt. Az egyik,hogy a processzorok cache-memóriájának tulajdonságait - ti. ami cache-ben van az sokkal gyorsabban megkapjuk + a cache tartalommal címezhető memória- kihasználva következtetni lehet memóriaterületek tartalmára. Ez tényleg minden modern processzorban megvan,de kihasználni nehéz,ha nincs más sebezhetőség.
A másik csak Intelt? érintő dolog ,hogy az Intel processzorok mindenféle ellenőrzés nékül végrehajtanak privilegikus hozzáféréseket (pl. a kernel memóriához) a spekulatív végrehajtás folyamán és csak a legvégén ellenőrzik,volt-e ehhez joguk. És ekkor hibát jeleznének,ahogy kell. DE a hacker bácsi szándékosan olyan kódot ír,ami mindig csak a spekulatív ágon hajtódik végre,így sose okoz hibát,de mivel a spekulatív ág nem törli maga után a regisztereket és a cache-t,így simán hozzá lehet jutni olyasmihez,amihez nem szabadna. Ez tervezési hiba,oka az lehet,hogy gyorsabb így a processzor,mivel kihagy ellenőrzéseket.
Móricka példával:
1. ....progi fut...
2. Spec = 1
3. If Spec = 2 //sose hajtódik végre
4 password = kernelmemória[400]
5. If Spec = 1 //mindig ez hajtódik végre
6. password megszerzése a spekulatív ágrólA 4. utasítás AMD (vagy régi Intel) procin simán privileged exception-t okoz és nem hajtódik végre,mivel nincs jogom a kernelmemóriát olvasni
Modern Intel procin nincs exception,ráadásul a cache-ben benne marad a [400] memóriacím tartalma. -
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.
-
tibaimp
nagyúr
Értem és köszi. Remélem maga a folyamat (mármint a törés folyamata) nem közérdekű, hogy minden újonc hekker ezzel szórakozzon. Mondjuk, lehet én nem is hoztam volna nyilvánosságra (persze az Intel attól "foltozgatta volna, meg a Win10 is frissítésekkel), de hát a szabad sajtó.....
A tehén egy bonyolult állat, de ÉN megfejtem...| 2016-tól az tuti, hogy az angyalok is esznek babot...
-
Alpi.
addikt
Van egy kinai csavo, aki abakusszal tudja tartani az 1 byte / fel ora tempot !! Avx sajna nem varhato arra.
https://www.youtube.com/channel/UCbJjHfBdTsUw3UJAFr-5Gsg
-
-
-
Tentalus
tag
Az igazán nagy veszélyben a nagy adatközpontban elhelyezett szerverek vannak,illetve a felhőszolgáltatások szerverei.Azért az nem rossz kindulási alap egy hackernek,ha én ugyanazon vason futtatom a programomat,mint a xxx bank vagy xxx autógyár,csak épp másik virtuális gépen.
Új hozzászólás Aktív témák
- Asus TUF RX 7600 XT 16G felbontott VGA, 3 év garancia, névre,cégre Áfá-s számla
- XFX Radeon RX580 OC+ 8GB
- Dynaudio Focus 220 hangfalpár
- Új Dell XPS 13 9315 Gyári dobozában, gyári töltőjével i5-1230u(8mag)/16RAM/512SSD/magyar bill.
- Üzletből, garanciával, Lenovo X1 Carbon ,i7-8665U/16GBRAM/512GBSSD FULLHD IPS matt/magyarított bill