Vlákno názorů k článku BranchScope je nový útok postranním kanálem na procesory Intel od Sten - Teď už jenom čekám, kdy někdo přijde s...
-
Sten (neregistrovaný)
Teď už jenom čekám, kdy někdo přijde s nápadem, jak jako side channel využít to, že 1 v RAM spotřebovává o trochu víc elektřiny než 0. Třeba flush (vynulování) cache, změření spotřeby, spekulativní nahrání zajímavých dát, změření spotřeby. Pokud by tam byl šifrovací klíč a vy zjistíte, kolik má 1 a kolik 0, tak už je velmi snadné jej prolomit.
-
Sten (neregistrovaný)
Spectre umí podobný únik, ale spekulativní běh se ale dá ovlivnit, aby k němu nedošlo tam, kde by mohl něco vyzradit (retpoline, KPTI). Ta data ale v RAM být musí, pokud se s nimi má pracovat (např. klíč pro šifrování disku) a měřením spotřeby by se dala vyčíst i bez spolupráce procesoru. Pokud se to někomu podaří, tak to bude mnohem blíž cold boot attack (s tím rozdílem, že to půjde za běhu) než Spectre.
-
Zas tak úplně jedno (co se děje na CPU) to není, protože pokud je systém napaden, tak šifrovací modul může podepisovat něco jiného než co je záměrem usera. Sice nevím jak to zneužít v souvislosti s touto chybou, ale často se setkávám s pocitem "mám šifrovací/podepisovací modul, jsem v bezpečí". Není to tak.
-
Prave proto existuji operacni systemy, aby si vsechna vlakna nebyla uplne rovna a jeste to kolikrat jisti MAC. Vzdyt si vemte jak tady omladina blazni ze Spectre a Meltdown, a pak jsou uneseni krabici all-in-one v podobe Turris na perimetru. Odseparovane sifrovani resi temhle expertum 130% problemu, to si snad muzeme mezi sebou septem rict ;)
-
Petr M (neregistrovaný)
1) V CMOS technologii se spotřeba nuly a jedničky neliší, je tam jenom peak při změně. Co se takto liší je náboj v DRAM, ale to je už mimo CPU.
2) Napájecí lajna je sdílená pro několik M hradel. Za předpokladu, že je to 16M hradel, nemáš šanci rozlišit jejich počet s ADC s rozlišením pod 24 bitů. Hradel tam dneska bude ještě víc a pokud chceš lokalizovat i oblast na čipu, potřebuješ měřit napájení z několika míst ještě přesnějším ADC...
3) Takto se ti v jedné lajně potká třeba 8 fyzických (16 logických) CPU.
4) Abys podchytil změny proudu u 3GHz CPU, budeš potřebovat podle vzorkovacího teorému samplovat na 6GHz minimálně.
5) Myslíš, že je sranda sestrojit čtyř nebo osmikanálový ADC s rozlišením 32 bitů při vzorkování > 6GHz a zpracovat data z něho v reálným čase včetně spárování s tím, co který CPU zrovna vykonává?
6) Stojí to úsilí za to, abys řekl, jestli se v CPU2 v taktu 54789652258298353687284 přeplo 26865757 nebo 26865758 hradel (absolutní hodnotu nevidíš a neidentifikuješ je)? -
Sten (neregistrovaný)
Vím, že je to velmi těžké, proto to zatím nikdo nedokázal. Ale pokud se mi podaří zjistit, kolik hradel se přeplo, a nějak zajistit, že předtím tam bylo vše 0 nebo 1 (to by u cache šlo jejím zaplněním), tak najednou vím, kolik je tam 0 a 1 a z exponenciální náročnosti brute force privátního klíče, ke kterému znám veřejný, je lineární. Ale i kdybych to nezjistil přesně, vědět, že ten klíč má mezi x a y jedničkami (a zbytek nuly), dost zrychluje brute force a ze 2^délka klíče se stane jen o trochu víc než 2^min(délka klíče-y+x, y-x).
-
Sten (neregistrovaný)
Pokud to jinak půjde, tak samozřejmě je lepší to udělat jinak, ale pokud to jinak nepůjde… Ono to ani nemusí být moc přesné nebo spolehlivé, aby to bylo použitelné. Ale tohle celé vlákno spíš byla úvaha, kam až by side channel útoky mohly dospět (do situace, kdy se proti nim prakticky ani nepůjde bránit), než že bych věděl o nějakém použitelném útoku. Kdybych o něm věděl, tak to nebudu psát na Root, ale zaregistruju si doménu Current Spectrage :-D
-
> klíč pro šifrování disku) a měřením spotřeby by se dala vyčíst i bez
> spolupráce procesoruPokud se podíváme na řešení šifrování disku ve Windows (TrueCrypt, VeraCrypt, snad i Bitlocker), klíč se nachází v paměti jádra, takže pokud pomineme Meltdown (což je rozhodně chyba), útočník by se k němu neměl z usermodu dostat.
Zatím jsem problém nestudoval do takové hloubky, abych pochopil, jak přes Spectre či tuto chybu číst paměť cizího procesu, která není s aktuálním sdílená, ale nestačilo by prostě ty citlivé údaje uložit do separátních paměťových stránek, kterým se nastaví oprávnění PAGE_NOACCESS, pokud tyto údaje nejsou potřeba? Jasně, nepomůže to zřejmě u věcí typu session klíče u SSL spojení (popř. jiných údajů, které se používají neustále), ale takové věci mívají krátkodobý efekt (pak se generují nové).
-
Sten (neregistrovaný)
Meltdown ani Spectre nejsou chyby per se, ale side channel útoky. Ty stránky nejsou tím procesem čitelné a ani se Spectre nebo Meltdown je ten proces nepřečte. Ale může ta nečitelná data získat tím, že spekulativní operace na nich, které lze pomocí jaderného API spustit v prostoru jádra, které má přístup ke všem stránkám, se sice necommitnou, ale mají vedlejší efekty, které jsou měřitelné. A umožňují získat klíče i pro TrueCrypt a VeraCrypt.
-
Chápu, že můžu pomocí volání jádra dostat určitou paměťovou stránku do cache a následně číst její obsah spekulativně (Meltdown). Moje otázka je, zda by to šlo (čtení paměti jádra) takhle i v případě, že by (teoreticky) procesor i při spekulativním vykonávání instrukcí kontroloval User/Supervisor bit ve stránkovacích tabulkách.
Že můžu takto spekulativně číst obsah paměti, pokud stránkovací tabulka dovoluje user přístup, je jasné.
-
Sten (neregistrovaný)
Meltdown jde opravdu zabránit, když se při spekulaci kontroluje ochrana stránek, ale Spectre obchází i tuhle ochranu: v prostoru jádra (po sysenter) se spekulativně načte hodnota z aplikaci nedostupné stránky a následně použije jako index do pole, které již je v prostoru dostupném té aplikaci. Ta aplikace pak jen zjistí, kterou část toho pole to načetlo do cache, čímž zjistí i to, jakou hodnotu indexu to použilo, tedy jaká hodnota byla na místě, odkud to to jádro načetlo (a kam aplikace nemá přístup). Nikde se přitom ale nenarazí na situaci, kdy by, i pokud by to nebylo jen spekulativní, byla porušena ochrana stránek, pouze se podaří spekulativně vykonat větev, která má nesplnitelnou podmínku na začátku (kontrolu mezí druhého pole, pomocí kterého se získá ten index). Jde tomu bránit tak, že se sysenter serializuje (vyžaduje změnu chování sysenter, těžko říct, jestli na to stačí aktualizace mikrokódu), pomocí něčeho jako retpoline hned po sysenter (zasekne spekulativní běh) anebo zavedením transakční cache (při rollbacku spekulace se rollbackne i vše, co se načetlo do cache, ale tohle vyžaduje docela velký zásah do architektury).
-
Peter FodrekZlatý podporovatel
KPTI ochrani len kernel a Navratova trampolina= RET tramPOLINE" by sa musela uplatnit cez kompilator v kazdom jenom SW, resp. kniznici, vratane SW z 50. rokov minuleho storocia...
-
Sten (neregistrovaný)
Pro většinu programů stačí retpoline po sysenter v jádře, z jednoho programu do druhého se totiž jinak než přes jádro nedostanete. Pak je ještě potřeba v SW sandboxech při komunikaci mimo sandbox (obdobě sysenter pro ten sandbox), takže třeba ve Chrome, ale vim nebo Kate retpoline nepotřebují.
ČLÁNKY DO MAILU