A DRAM "rowhammer" probléma kihasználása kernel szintű privilégiumokhoz jutás érdekében

 ( trey | 2015. március 10., kedd - 8:43 )

DRAM "rowhammer" hiba

A gyártóknak abbéli törekvésükben, hogy minél kisebb és gyorsabb memóriákat gyárthassanak, számos kompromisszumot kell kötniük. Ilyen kompromisszum például, hogy egyre kisebb fizikai mérettel kell dolgozniuk. Az egyre kisebb fizikai méretek miatt a memóriacellák nagyon közel helyezkednek el egymáshoz. Annyira közel, hogy az egyik memóriacella töltése átszivároghat a szomszédos cellába és ott bit átbillenést idézhet elő. Az ipar szereplői felfigyeltek arra, hogy ez bizony nem csak elméleti probléma, hanem bizonyos körülmények közt meg is történik. Például olyankor, amikor a memóriavezérlő az egyik memóriasornak folyamatosan ACTIVATE parancsokat küld. Ha egy szomszédos sor (Victim Row) egy ideje nem kapott aktiválást vagy frissítést, akkor a folyamatosan aktivált sorból átszűrődő "hammering" bithibát okozhat benne. A hiba onnan kapta a "Row Hammer" nevet, hogy a memória egy sorát ACTIVATE paranccsal "kalapáljuk".


"Rowhammer" probléma

A tudomány jelen állása szerint ez fizikailag nem károsítja a memóriacellákat. A probléma előállhat rosszindulatú tevékenység, de akár szabályos működés közben is. Szabályos működés közben a "rowhammer" problémát akár a szemaforok használata is előidézheti.

A Google biztonsági csapata azonban felfedezte, hogy a "rowhammer" problémát privilégiumszerzésre irányuló támadásokban is fel lehet használni. Több laptopot is megvizsgáltak és arra jutottak, hogy egy részükön jelentkezik a probléma.

A Google Project Zero csapatának tagjai két működő privilégiumszint-kiterjesztést lehetővé tevő exploitot is készítettek a probléma demonstrálásra. Az egyik exploit 64 bites Linuxon "rowhammer"-okozta bitátfordulást használ fel kernel szintű privilégiumokhoz való jutáshoz.

Linkek:

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Lehet csak a hozzá nem értésem végett - de számomra az nem világos, hogy virtualizált (xen, vmware) környezetben is működik-e ez a 'bug'?

Tehát lehet-e ilyen módon ráhatása egy virtuális gépnek a fizikai memóriára?

--
zrubi.hu

Lehet.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Átüt a tinta a Turing-gépben. :)

Nem, virtualizálva nem működik mivel a ram címekhez nincs közvetlen hozzáférés.
Ha nincs ECC vajon a zram önmagában védelmet jelent?

Érdekes. Ecc-t mindenbe.

Az használ ez ellen?

Mitigations and Fix

--
trey @ gépház

A "victim" jó eséllyel paritás hibás lesz, amit az ECC korrigál 1 bitig vagy hardver leállást okoz privilégium szint emelés helyett.

Nem tudom elképzelni, hogy hogyan tudna 1 bitig korrigálni.

Saccra nem ezeket használják, hanem a mátrix paritást. Vagy a mátrix paritás egyfajta Hamming-kód lenne?

Szerk.: tévedtem, lejjeb van egy link, amelyik szerint "distance 4" kódot használnak, ami egy Hamming-kód.

Ezért kellene tarkón vágni az Intelt, hogy a mobil és a desktop processzorai még mindig nem támogatják az ECC-t...

Szerinted az emberek kifizetnének plusz 5% plusz pénzt érte?

Ha csak +5% lenne, siman.
ECC -n enterspajz sap van, joval tobbe kerul.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Esélyes, hogy ott van bennük, legalábbis desktopon, csak le van tiltva.
Annó már az 440LX chipset is támogatta az ecc-t, emlékszem '99-ből az ilyen alaplapomra. Azok kifejezetten belépő szintűnek voltak eladva és akkoriban mégis tudták. Szóval a butítás inkább csak üzleti döntés, hogy ne építsenek normál procira szervert vagy munkaállomást, helyette vegyenek sokkal drágábban olyat, amiben nincs letiltva.

Egyébként intelnél rákeresve látszik ,hogy össze vissza van az ecc támogatás, van olyan atom és celeron is, amiben meghagyták a memóriavezérlőben.
http://ark.intel.com/search/advanced?s=t&ECCMemory=true

Tisztában vagyok vele, hogy pusztán üzleti döntés és piac szegmentálási célokat szolgál, ezért tartom undorítónak a dolgot...

A régi alaplapokon még az északi hídon volt a memóriavezérlő, amióta a processzorba integrálták, azóta vágta meg az Intel különösen az ECC támogatását (de már a P4-eknél elkezdték ezt, ha jól emlékszem).

Az ECC-t támogató Atom processzorok a szerver és a telekommunikációs területeket célozzák meg, ahova nyilván nem tudják nélküle eladni. Van néhány újabb Haswell szériás processzor, amelynél valóban íják az ECC támogatást, de egyrészt érdemes az ark.intel.com információit óvatosan kezelni, mert üzleti célokat szolgál és nem pontos technikai adatokat tartalmaz (többször találtam már pontatlanságokat a leírásokban), másrészt jól mutatja, hogy nincs egyértelmű elhatározásuk továbbra sem az ECC mellett a Haswell óta, hisz az újabb mobil Broadwell processzorokban továbbra sincs hozzá támogatás. Kiváncsi leszek, hogy a desktopban lesz-e, de kevés esélyt látok rá...
http://ark.intel.com/search/advanced?s=t&CodeNameText=Broadwell&ECCMemory=true

Engem nem ez lep meg. Sokkal furcsább számomra, hogy a
számítógép egyáltalán működik. Annyi biszbasz van benne,
hogy szinte hihetetlen, évekig teszik a dolgukat.

> Sol omnibus lucet.

+1

--
NetBSD - Simplicity is prerequisite for reliability

Boldogok a ...

Már ezen a kijelentésen is túlment az idő. Egy kocsiban szerintem simán lehet 30-40 párhuzamosan dolgozó mikroszámítógép, amelyik dumál egymással.

Nem azon kell csodálkozni, hogy mennek, hanem hogy eközben még hálózatba is vannak kötve és pofáznak egymással.

A kínaiak már a gagyi voltmérőkbe is számítógépet raknak, ADC-vel mintavételez, az eredményt meg nyomja a 7 szegmenses kijelzőre. 300 Ft-ért szállították nekem ki postaköltséggel együtt.

:)

Néha úgy érzem hogy a többi szakmámból kéne inkább megélnem... ehe.

Ez azért olyan szép, hogy már-már művészet.

Minden szakmát lehet olyan szinten művelni, ami már-már művészet. Sajnos nagyon kevesen jutnak el ilyen szintre. Én sem fogok soha :)

azt nem értem, hogyan tudják kontrollálni a PTE-knél a bit flipeket? mert azért ha egy high bitet flipelnek ami kimutat a memóriából, akkor annak gondot kéne okoznia, nem?

Ez van ha az MCU IP az NSA -tol jon :)


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Tök jó. Nagy öröm, hogy ilyen gyorsan fejlődünk, és a hardver egyre gyorsabb és megbízhatatlanabb alattunk, amit az egyre lassabb és megbízhatatlanabb a szoftver ellensúlyoz... (Mindjárt megkérdem a rendszergazdától maradt-e még egy kis ferrites memória: amit abban tárolunk, az mindent túlél. Mondjuk a kiolvasást pont nem, de ne legyünk telhetetlenek.)

Most úgy érzem magam, mint az a bizonyos Józsi bácsi a repülőn: erre azért nem számítottam.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Hogy halad a memrisztor-alapú gépek kutatása?

Röviden el tudná magyarázni valaki, hogy egy ilyen hiba hogyan használható ki? Hogyan lehet privilégiumszerzésre használni?

Előre is köszi.
----
"Mert nincs különbség: mindenki vétkezett, és híjával van az Isten dicsőségének. Ezért Isten ingyen igazítja meg őket kegyelméből, miután megváltotta őket a Krisztus Jézus által." (Róma 3.22-24)

szerez egy page tablet magának amire van read/write access, ezen keresztül pedig úgy módosít akármilyen memóriát a gépen ahogy csak akar

Habár nem értek belőle semmit, ez bőven már elég ahhoz, hogy elinduljak. Köszi.

----
"Mert nincs különbség: mindenki vétkezett, és híjával van az Isten dicsőségének. Ezért Isten ingyen igazítja meg őket kegyelméből, miután megváltotta őket a Krisztus Jézus által." (Róma 3.22-24)

:D ?


No rainbow, no sugar

olvasd el google cikket

--
NetBSD - Simplicity is prerequisite for reliability

Csak kérdezem, ezt a hibát támadásként hogy lehet kihasználni valóságos körülmények között?

Inkább amiatt aggódnék, hogy direkt vagy véletlenül ezt kihasználó alkalmazások jönnek vagy jöttek létre.

Google Project Zero csapatának tagjai két működő privilégiumszint-kiterjesztést lehetővé tevő exploitot is készítettek a probléma demonstrálásra. Az egyik exploit 64 bites Linuxon "rowhammer"-okozta bitátfordulást használ fel kernel szintű privilégiumokhoz való jutáshoz.

Szóval ki lehet használni valós körülmények között, bár nem minden desktopon.

Ez egy nem életszerű módszer, inkább demonstráció a banális hiba bizonyítására. Viszont mostantól ezeket a kódokat könnyen integrálhatják mostani alkalmazásokba.

mi van?

--
NetBSD - Simplicity is prerequisite for reliability