Názory k článku
RAMBleed je útok na citlivá data v paměti postranním kanálem
-
Toto je moc hezký problém, který ukazuje, že ne všechno se dá házet na odpovědnost výrobce hardwaru. U chyb v procesorech jsou věčné dohady o (ne)zodpovědnosti výrobců, zatímco vývojáři softwaru (operačních systémů) jsou pomalu za oběti. Já si to třeba nemyslím, já si myslím že OS vendor by měl o hardwaru vědět stejně hodně, jako výrobce hardwaru o operačních systémech.
Tento typ hrozby na RAM ukazuje, že hledat "viníka" je opravdu složité.
-
Petr StehlíkZlatý podporovatelPokud se v RAM změní hodnota na adrese, kam nebylo zapisováno, tak je to jasná vada HW, to je bez diskuse. SW, OS, vendoři s tím nemají nic společného. Výrobce HW se musí víc snažit vyrobit paměť, která funguje normálně.
-
To je alibistický pohled.
Auto má brzdy, které ho mají umět zastavit. Ale destičky mohou být sjeté a kotouče prasklé. Během provozu mohou být přehřáté a ztratit brzdný účinek. Může dojít k blokaci kol a roztavení gum a ztrátě adheze. To všechno jsou jevy, za které brzdy nemohou, ale souvisí s fyzikální podstatou jejich fungování - a vytratí se jejich primární účel: auto nebrzdí. Automobilka pak mohla ječet na výrobce brzd (a on zase na automobilku, že vyrábí moc výkonná auta), nebo mohli společně vynalézt kotouče s vnitřním chlazením a ABS.
Zkuste mi prosím popsat, jak rozlišíte chybu od specifik technologie?
-
Filip JirsákStříbrný podporovatelV tomto případě se ale hodnota na jiné adrese nemění, „jenom“ je možné ji odvodit. Za druhé, samozřejmě je možné udělat ultrabezpečný hardware, který zároveň bude pomalý a drahý. Ale pokud někdo chce pařit nějakou střílečku v rozlišení 4K, chce, aby jeho hardware byl rychlý, a je mu úplně jedno, že útočník může číst nebo dokonce měnit obsah RAM.
-
Jinak si myslim, ze to uz je dost slusna cesta jak ziskat data. Kdyz uz je ta informace venku, tak mi prijde na mysl, no jasne, to dava smysl a jde to snadno pochopit, ale koho by to napadlo kdyz se na to diva z pohledu vyrobce. Ten resi uplne jiny pohled a to jak tam ty data dostat ve stavu v jakem maji byt pri te dnes uz silene rychlosti a variabilni teplote ktera ma na data taky vliv. Proste vyrobce ma prioritu ty data zapsat a pak je i precist. Ted aby resil jak ty data zabezpecit. A jak tady zaznelo a bylo vyminusovano, nejjednoduseji by to slo s vyrobcem OS, jinak musi vyrobce hw predpokladat, ze vsechna data nesmi touto metodou detekovatelna (jake jine cesty tim otevre se zjisti az posleze) Silene je si vubec predstavit co vsechno by to stalo, uz jen zmena navrhu a jeji otestovani a pak nekdo prijde s necim jinym a zaciname odznova. Co kdyby byla funkce ktera by mela security flag a pri zapisu do pameti by donutila okolni bunky prestehovat, nahodne prepsat data a tim znemoznit detekce. Samozrejme by to bylo narocnejsi u teto operace, ale bezpecnost neco stoji... treba strojovy cas....
Jasny, mozna kravina, ale zas tak trivialni reseni to nebude.13. 6. 2019, 18:31 editováno autorem komentáře
-
Není pravda, že "se ale hodnota na jiné adrese nemění". Už v tom úvodním popisu se dočtete, že "RAMBleed is based on a previous side channel called Rowhammer, which enables an attacker to flip bits in the memory space of other processes. We show in our paper that an attacker, by observing Rowhammer-induced bit flips in her own memory, can deduce the values in nearby DRAM rows."
A o něco níže na téže stránce je základní myšlenka popsaná podrobněji: "Rowhammer induced bit flips are data dependent, i.e. a bit is more likely to flip when the bits above and below it have the opposite charge. ... an attacker can deduce the values of bits in nearby rows by observing bit flips in her own memory rows. ... This causes the bit flips in the attacker's rows to depend on the values of the victim's secret data."
Chcete i po přečtení těchto citací dál tvrdit, že k provedení RAMBleed útoku není potřeba, aby paměť umožnila nevyžádané bitflipy ("Rowhammer"), a tedy aby se chovala nekorektně?
-
Filip JirsákStříbrný podporovatel
Máte pravdu, mění se hodnota v paměti mého procesu, ale je to jiná adresa, než na kterou zapisuju.
Jestli to je nebo není nekorektní chování paměti je otázka. S tím, že může dojít k nechtěnému překlopení bitu, se počítá – proto máme ECC paměti, které by to měly odhalit. Nepočítalo se s tím, že to překlopení může někdo vyvolat záměrně ze sousedního procesu, ale z hlediska ochrany před překlopením bitu je jedno, proč k tomu dojde, podstatné je to, že k tomu dojít může.
-
Ne, není to "otázka". Pokud dodržím specifikace - a od toho paměť sama poskytuje profil se specifikací přípustných parametrů - a paměť změní hodnotu buňky, do které jsem nezapsal, je to chyba, to není žádná "otázka". ECC existuje proto, že se počítá s určitou, velmi nízkou pravděpodobností, že k nějaké náhodné chybě přesto občas dojít může.?
RowHammer je problém z úplně jiné kategorie, tam k bitflipu při určitém patternu zápisu dojde s tak velkou pravděpodobností, že to za něco jiného než designovou nebo konstrukční chybu může považovat jen právník firmy, která ty paměti vyrábí.
Všiml jste si někdy, jaké testy provádí třeba memtest86 nebo podobné testovací programy? Také zkoušejí velmi specifické patterny, které jsou výrazně náchylnější na vyvolání chyby. A když nějakou chybu najdou, tak to není žádná "otázka", je to prostě chyba a nemávne se nad tím rukou, že "se nepočítalo s tím, že někdo může zapisovat zrovna takovéhle divné patterny v takovémhle pořadí".
To, že některé chyby hardware jsou v podstatě důsledkem toho, jak jsou ty chipy navrženy, a že se jich tudíž výrobci neumějí bez zásadního přepracování (které bude trvat roky) zbavit, je nemilé a musíme se s tím naučit nějak vypořádat. Ale je naprosto neakceptovatelné, že se, ať už jde o CPU nebo o paměti, čím dál víc šíří fatalistický přístup "no jo, s tím se holt nedá nic dělat, tak to být prostě musí" nebo dokonce "oni si za to vlastně mohou sami, nemají s tím dělat takové divné věci". To bych taky mohl víceméně každou bezpečnostní chybu, na kterou se přijde fuzzingem nebo která se vyvolá nějakým netypickým způsbem použití, odpálkovat, že "no jo, s tím se prostě nepočítalo", a vykašlat se na ni.
-
Filip JirsákStříbrný podporovatel
Pokud k chybě může dojít a pro uživatele by ta chyba byla fatální, je naopak nekorektní chování uživatele, který spoléhá na to, že ta chyba je tak málo pravděpodobná, že ji vlastně vůbec nebude řešit.
Já netvrdím, že se s tím nedá nic dělat. Ale pořád platí klasický trojúhelník – ze tří vlastností bezpečnost/korektnost, rychlost a nízká cena můžete mít vždy jen dvě. Holt ten pokus, že budeme stavět servery z levných spotřebních komponent určených pro osobní počítače, nevyšel, a budeme se muset vrátit k tomu, že se servery budou stavět z jiných, bezpečných ale drahých, komponent.
Ano, s tím se prostě nepočítalo. Na tu chybu ale nikdo nekašle, akorát její řešení prostě znamená, že ty komponenty budou dražší – a spousta lidí nebude ochotná tu vyšší cenu platit, protože je ta chyba nijak vážně neohrožuje.
-
za něco jiného než designovou nebo konstrukční chybu může považovat jen právník firmy, která ty paměti vyrábí
Znovu zpět k autům: ABS se začalo montovat, protože nejčastěji při nedodržení dostatečné řidičské opatrnosti a obratnosti při brzdění docházelo ke ztrátě adheze. ABS však nezaručí, že auto nepřivedete úmyslně za hranu toho, čemu je ABS schopno zabránit.
Zde jde o to, jestli: 1) je ochrana vůbec možná, 2) o kolik s zvýší cena modulů? 3) o kolik se sníží cena modulů? 4) bude zákazník preferovat vyšší rychlost, nižší cenu, nebo absolutní bezpečí?
To, že některé chyby hardware jsou v podstatě důsledkem toho, jak jsou ty chipy navrženy, a že se jich tudíž výrobci neumějí bez zásadního přepracování (které bude trvat roky) zbavit, je nemilé a musíme se s tím naučit nějak vypořádat.
Řeknu Vám, že Henry Ford byl strašný pitomec, protože navrhnout auto s tolika chybami (jak se nám jeví dnes), by nikdo normální nemohl. Se divím, že ho už tenkrát neukamenovali.
-
Ano dochází ke změně, jak píštěte.
V článku je ale zavádějící tvrzení, které místní přispivatele mate: "Jelikož nedochází k pozměňování stavu okolních buněk, nepomůžou v tomto případě ani paměti ECC."
Toto v daném spojení není správný výrok. Ta část "nepomůžou v tomto případě ani paměti ECC" je správně. Nikoliv však ono zdůvodnění.
Viz článek:
"synchronous nature of the ECC correction algorithm typically exposes such information through a timing channel, where memory accesses that require error correction are measurably slower than normal accesses."Tedy ten důvod proč ECC nepomůže, není v tom, že by se nic neměnilo (a neopravovalo), ale v tom, že když se něco (čte a) opravuje, trvá to určitou dobu (ve srovnání s tím, když se nic neopravuje) a podle toho dokážete odhadnout, zda ke změně došlo či nikoliv. To v kombinaci s tím, že ke změně dochází pouze, pokud jsou v okolí bity určité hodnoty umožní odvodit hodnoty bitů v okolí.
-
Ona to není zas tak docela vada HW, spíš vada specifikace. HW je navržené tak, aby za normálních okolností fungovalo. K opakované aktivaci řádku při obvyklém využití nedochází, jelikož opakované přístupy jdou z cache. Jen se v té specifikaci nepočítalo s bezpečnostním aspektem. Specifikace DDR4 už na to přináší hotfix v podobě target row refresh pro sousední řádek při příliš časté aktivaci.
Kdyby to mělo být odolné na hw úrovni, tak by asi ten čip byl větší a dražší, a nikdo by ho nekoupil, takže by takový čip ani nebyl, že. Jelikož by se mezi řádky musela vkládat nějaká izolace nebo aspoň větší rozestup. I ten TRR u DDR4 to zesložiťuje a proto je ve specifikaci nepovinný. -
Jak AMD tak nvidia Tegra SoC maji funkce pro transparentni sifrovani pameti. I kdyby byl algoritmus znamej, tak klic znamy nebude - protoze to muze byt veci kazdeho bootu a predpokladam ze z duvodu bezpecnosti k nemu pristup nebude.
Takto udelany system by mel byt bezpecny vuci podobnym utokum z principu ze v pameti nebudou nikdy stejne stavy a onen sum po zafrovani bude mit vyvazenou stredni hodnotu.
-
Teda neviem, mozno som nieco len zle pochopil, ale mne to pripada ako ako burka v lyzicke vody. Viete si niekto predstavit realny exploit postaveny na tejto zranitelnosti? Ste proces v OS, mate namapovany nejaky virtualny adresny priestor - ako zistite do ktorych fyzickych buniek chipu sa presne mapuje? Ako zistite ktoremu procesu patria tie bunky hned vedla?
Pokial nemate pristup do kontextu jadra OS, tak asi velmi tazko (a pokial ho mate tak to predsa nebudete robit takto komplikovane).
