Názor ke zprávičce AMD upozornila na chybu v CPU Zen 3, může vést k útoku Spectre V4 (Speculative Store Bypass) od Wladows - Uznávám, že jsem svůj popis Spectre útoku zjednodušil...

Uznávám, že jsem svůj popis Spectre útoku zjednodušil až moc, ale nechtělo se mi to rozepisovat do posledního detailu. Kdo má zájem, může si to nastudovat nebo to už zná.

Na druhou stranu, cache představuje jakýsi 'otisk prstu', který za sebou zanechává každá zpracovaná instrukce. Pokud si někdo dá tu práci, aby přesně zmapoval co sledovaný program dělá, tak může z obsahu cache vyextrahovat nějaké informace o předchozím běhu programu.

Názorně je to vysvětleno v těchto článcích z roku 2005 (tedy více než desetiletí před útoky na spekulativní vykonávání, BTB, atd.). Tehdy přišly na trh nové procesory Pentium 4 vybavené hyperthreadingem. Ten umožňoval dvěma threadům (klidně z různých procesů) sdílet nejen výkonné jednotky, ale taky L1 cache. Tam jsou nejžhavější informace o tom, co se právě teď dělo...

https://news.netcraft.com/archives/2005/05/20/researcher_attack_could_expose_ssl_certs_on_shared_servers.html
- http://www.daemonology.net/papers/htt.pdf
- https://cr.yp.to/antiforgery/cachetiming-20050414.pdf

Toto je pokračování z roku 2019:

https://eprint.iacr.org/2018/1060.pdf

Špehování cache se dá výrazně omezit velmi promyšleným způsobem implementace kryptografických funkcí tak, aby se z přistupovaných adres nedaly zpětně odvodit např. bity z hesla, privátního klíče, apod. Např. tím, že kód vždy přečte celé pole, i když potřebuje jen jeden údaj. Nebo výpočet pokračuje i přesto, pokud je už známo, že třeba klíč není platný. Nebo pokud před samotným výpočtem se načtou (prefetch) úplně všechna nutná data z paměti do cache (klíče, S-boxy, apod.), aby se kód vždy vykonával z cache a nedalo se manipulací předchozího stavu cache odhadovat na co se sahalo. Následně po konci výpočtu opět všechno (i opakovaně kvůli přemazání LRU historie) načíst do cache, aby se zahladily stopy. Možností je hodně, ale není to jednoduché. Např. je nutno zajistit, že to bude bezpečné na všech podporovaných platformách a druzích a verzích překladače. Taky je nutné ověřit, že překladač např. při optimalizaci nevyhodil 'zbytečné' čtení datových struktur, které se přímo v cyklu nepoužívají. Gcc je známé velmi agresivními optimalizacemi, které mohou způsobovat i bezpečnostní díry, např. kompletní odstranění volání memset() na vymazání hesla v řetězci na zásobníku na konci funkce. Vždyť ty nově zapisované hodnoty nikdo nečte (kromě útočníka), tak proč ztrácet čas s jejich zápisem...? Je toho hodně, takže nakonec nezbude než si přečíst přímo vygenerovaný assembler a ověřit si ručně, že tam je všechno co tam má být.

Nejen cache se dá šikovnou manipulací a měřením zneužít. V podstatě jakékoliv stavové informace v procesoru, které se během zpracování mění nebo dokonce na nich závisí vykonávání příštích instrukcí (cache, BTB/prediktor skoků, store buffers, různé fronty a spousta dalších implementačně závislých věcí).

10. 4. 2021, 03:54 editováno autorem komentáře