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

Titkosítás, biztonság, privát szféra

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:

( zrubi v | 2015. 03. 10., k – 09:02 )

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

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&ECCMemo…

Intel is using the same Core i3 processor at both Desktop as server platforms So when Core i3 processor is inserted in to a server chipset platform, like with intel 3400/3420/3450 chipset,then the CPU will support ECC with UDIMM. On the other hand if Core i3 is pluged into a Desktop chipset mainboard, like with P55, H55… chipset, then CPU won’t have ECC support function. So with X8SIL-F using Server 3420 chipset,you need to install unbuffered ECC memory in combination with Core I3 processor.

( meditor | 2015. 03. 10., k – 09:15 )

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.

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.

:)

( Fisher v | 2015. 03. 10., k – 09:32 )

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

( cheeky v | 2015. 03. 10., k – 09:32 )

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

( zephyrus | 2015. 03. 10., k – 09:39 )

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?

( turul16 v | 2015. 03. 10., k – 09:42 )

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

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( NevemTeve | 2015. 03. 10., k – 10:11 )

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.)

( locsemege v | 2015. 03. 10., k – 11:21 )

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

( persicsb | 2015. 03. 10., k – 11:38 )

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

( Rackshee | 2015. 03. 10., k – 15:47 )

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)

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)

( freeoli v | 2015. 03. 11., sze – 10:30 )

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.