ÚJABB SÉRÜLÉKENYSÉG FENYEGETI A MODERN PROCESSZOROKAT

BranchScope névvel egy újabb sérülékenység jelent meg, ami a Spectre második variánsához hasonlóan a spekulatív végrehajtást támadja, de más módszert használ.
Víg Ferenc (J.o.k.e.r)
Víg Ferenc (J.o.k.e.r)
2018. márc. 29. 8:01
Újabb sérülékenység fenyegeti a modern processzorokat

Ebben az évben eddig a sérülékenységeké a főszerep, ugyanis folyamatosan bukkannak fel az érdekesebbnél érdekesebb biztonsági rések, amelyek komoly feltörést okoznak a hardvergyártóknak és a szoftverfejlesztőknek. Az év elején a Meltdown és a Spectre miatt tört ki pánik a piacon, néhány hete pedig az izraeli CTS Labs felfedezései borzolták a kedélyeket – ráadásul a biztonságtechnikai kutatók nem is voltak túl etikusak, amikor ismertették a hibákat.

Most négy akadémikus újabb biztonsági rést talált, amely a Spectre második variánsához hasonlít, módszertana azonban eltérő. A szakemberek, vagyis Dmitry Evtyushkin, Ryan Riley, Nael Abu-Ghazaleh, és Dmitry Ponomarev természetesen betartották az ilyenkor érvényben lévő íratlan szabályokat, vagyis időben értesítették a gyártókat az ügyről, csak ezután publikálták a felfedezést.

A sérülékenység a modern processzorok spekulatív végrehajtó rendszerét támadja, csak úgy mint a Spectre 2. A BranchScope névre keresztelt sérülékenység viszont nem a Branch Target Bufferen keresztül próbál adatokhoz jutni, hanem a Directional Branch Predictor sérülékenységeit próbálja kiaknázni. Ez a komponens irányítja tulajdonképpen azt, hogy mely spekulatív műveletet hajtsa végre a processzor. A támadók e komponens működésébe tudnak belenyúlni egy megfelelően megírt kód segítségével, amelynek lefuttatásához nem kell emeltszintű jogkör, vagyis felhasználói szintű jogosultság mellett is kiaknázhatóak a sebezhetőségben rejlő lehetőségek. A támadó a megfelelően megírt kód segítségével beavatkozhat a Directional Branch Predictor működésébe, így eltérítve azt olyan memóriaterületek tartalmához juthat, amelyek korábban nem voltak elérhetőek – egyszerűen azzal, hogy az eltérítés során e memóriaterületek tartalmát „olvastatja ki a processzorral”.

Ehhez első körben módosítania kell a Pattern History Table tartalmát, amihez véletlenszerű blokk formájában tálalt elágazás-műveleteket kell használnia. Ezután a támadó elindítja egy olyan elágazás végrehajtását, amelyet meg szeretne figyelni az áldozat-folyamaton keresztül, majd meg kell várnia, hogy az áldozat aktivitásának eredményeként módosuljon a PHT állapota. Ha ez kész, a támadó még több elágazás-műveletet indít, amelyek ugyanazt a PHT bejegyzést célozzák, amit az áldozat folyamata, ezzel egy időben pedig időzíti őket, hogy megfigyelhesse a becslések eredményeit. A támadó a becslések végkimenetelét korrelálja a PHT állapotával, hogy azonosíthassa az áldozat elágazásának irányát. A támadónak ütközést kell okoznia a saját és az áldozat elágazásai között a PHT-ben, ami nem nehéz, hiszen az áldozat kódjának virtuális címe általában nem titok. Amennyiben ASLR-t használ az adott rendszer a kódhelyek véletlenszerűvé tételéhez, a támadó de-randomizálással vagy oldalcsatorna-támadással is elérheti a célját. A kutatók által publikált PDF a támadás egyéb részleteire is mélyen kitér, így akit ez érdekel, itt találja a dokumentumot.

A sérülékenység hatásait szoftveres javításokkal lehet kezelni, de igazából a hardveres működés módosítása jelenthet megnyugtató védelmet a támadásforma ellen. Ennek keretén belül randomizálható a PHT, akár periodikusan is, ami némi teljesítményvesztést okozhat. Megoldás lehet az is, ha az érzékeny elágazásoknál egyszerűen elvetik az elágazás-becslés használatát, így nem szivároghat ki érzékeny adat. Ez szintén okoz némi teljesítménycsökkenést, ugyanakkor a szoftveres megoldáshoz hasonlóan nem biztosít védelmet a burkolt oldalcsatorna támadások ellen (Covert Side-Channel Attacks).

A legjobb megoldásnak a BPU particionálása jelentheti, így a támadó és az áldozat nem használhatják ugyanazokat a struktúrákat. Alternatív módon privát partíció létrehozását is kérhetik az egyes kódok, ami szintén megoldás lehet. Ezzel a megoldással a támadó nem tud összeütközéseket generálni a saját és az áldozat folyamatai között, így efféle támadásra sincs módja – kihúzható a sérülékenység méregfoga.

Alternatívaként a támadó időzítési képességét is lehet gátolni: zajt lehet adni a teljesítmény számlálókhoz vagy az időzítő mérésekhez. Akár a támadó folyamatát is felismerhetné a rendszer, majd lefagyaszthatná vagy megbéníthatná. Ezt SGX kontextusban az operációs rendszer megtámadásakor persze nehéz lenne kivitelezni, de azt el lehetne érni, hogy az SGX kód úgy dönthessen, hogy támadás esetén újra-térképezi magát vagy befejezi a végrehajtást.

A kutatók szerint a sebezhetőség sikeresen kiaknázható a Sandy Bridge, Haswell és Skylake processzorok esetében, ezekre ugyanis már vannak példakódok. Az újabb processzorokról egyelőre nincs hír, mint ahogy arról sem, hogy az AMD központi egységei érintettek-e. A jelek szerint még tesztelni kell őket.

A processzorgyártók hírünk írásakor még nem adtak ki hivatalos közleményt azzal kapcsolatban, hogyan és mikor foltozzák be az újabb sérülékenységet, de ha bármiféle változás történik, azonnal beszámolunk róla.

Hírlevél feliratkozás
A feliratkozással elfogadom a Felhasználási feltételeket és az Adatvédelmi nyilatkozatot.

15 hozzászólás

A komment írásához előbb jelentkezz be!
rini
rini
2018. márc. 29. 12:09
#7

Ne gondold azt, hogy akár a régi (például 286/386 vagy éppen az AMD akkori variáns) processzoroknál nem volt tele sérülékenységekkel a rendszer. Így vagy úgy de ha valaki ért hozzá, van elég pénz a háta mögött és akar ilyen hibákat találni, akkor idővel fog is. Ráadásul az egyre újabb és újabb processzorok egyre bonyolultabbak, így egyre több hibalehetőséget is tartalmazhatnak.

csabi02
csabi02
2018. márc. 29. 17:13

Ennyi!

Törölt felhasználó
Törölt felhasználó
2018. márc. 29. 12:05
#6

Ez sem rossz. :D

[Total Meltdown]

axe
axe
2018. márc. 29. 11:58
#5

gondolom csak a véletlen műve, hogy pár állam vagy ország saját processzort kezdett el csinálni pár éve....

kazsakke
kazsakke
2018. márc. 29. 10:11
#4

Dolgok amik Harvard architekturan nem fordulnanak elo :)

Chavalier
Chavalier
2018. márc. 29. 9:34
#3

Már veszem is az intel 4004-et ebayről, abba talán nem terveztek kiskaput :D

seahorsekft
seahorsekft
2018. márc. 30. 18:10

Áh, menj biztosra, rakd össze tranzisztorokból magad!

http://www.4004.com/mcs4-masks-schematics-sim.html

katt777
katt777
2018. márc. 29. 9:13
#2

Mintha a Kaby Lake nem ua. architektúra lenne...

Vajon mikor derül ki az összes direkt beépített kiskapu? Gondolom, már javában dolgoznak a helyettesítésükön, mert az mégsem járja, hogy a 3 betűsek ne férjenek hozzá mindenhez a gépünkön.:O

TheEngineer
TheEngineer
2018. márc. 29. 11:48

Igazad van, de ettol fuggetlenul hajlok arra, hogy ez speciel pont nem ezzel a cellal jott ossze igy. Ertsd, amellett hogy van bennuk, ez pont nem az.

ChoSimba
ChoSimba
2018. márc. 29. 8:46
#1

Na akkor itt az ideje a 486-oshoz visszatérni, azon még nem volt BPU. Van valakinek esetleg win3.1 telepítője ? :)

TheEngineer
TheEngineer
2018. márc. 29. 9:07

Nem gond, megoldjuk okosba'! ;)

Ugyanitt simm memoria ertekegyeztetessel elado... :D

Vissza az oldal tetejére