
Před časem prosákla zpráva, že Intel (a zřejmě i další výrobci procesorů) opět pod NDA řeší bezpečnostní zranitelnosti podobné chybě Spectre ze začátku letošního roku. První příděl těchto chyb byl včera odhalen v podobě chyby označené CVE-2018-3639, neboli „Speculative Store Bypass“. Tato zranitelnost se podobá chybě Spectre a opět spočívá přímo v architektuře jader out-of-order procesorů – nelze ji tedy nějak jednoduše zazáplatovat. Jde o další ze skupiny útoků na spekulativní provádění kódu a je tedy řazena k Spectre a Meltdownu jako „varianta 4“ těchto děr.
Podrobnosti publikoval Microsoft a Google Project Zero, koordinovaně s výrobci procesorů Intelem, AMD a ARMem, jichž se zranitelnost všech týká. Pro zjednodušení lze asi momentálně říci, že alespoň u běžných uživatelských PC by neměl být dopad této chyby velký a mělo by stačit, pokud budete jako vždy udržovat operační systém a prohlížeč webu aktuální. Nejde tedy asi o tak závažnou zranitelnost jakou je Meltdown a Spectre. Nepříjemné riziko ale představuje.
Útok na spekulativní čtení dat
V čem chyba spočívá? Slabým místem je opět spekulativní vykonávání práce v procesoru, ovšem tentokrát lokalizované do load/store pipeline. Moderní CPU čtení a ukládání hodnot mezi pracovními registry procesoru a operační pamětí také provádějí stylem out-of-order, neboť to dovoluje zvýšit výkon a prostupnost vstupu a výstupu a zamezit ve výpočetních jednotkách prostojům při čekání na data. Tato technika se často označuje jako Memory Disambiguation a možná si ji pamatujete jako jednu z velkých novinek architektury Intel Conroe z roku 2006. Ovšem podobně jako mezi instrukcemi programu mohou i mezi čteními a zápisy být závislosti. CPU například musí hlídat, aby iniciativně nepřečetlo (což je „load“) data z adresy, do které by směřoval nějaký zápis, jenž má dle posloupnosti kódu předcházet („store“). Jinak by CPU dostalo neaktuální a chybná data.
Procesory proto používají techniky, které toto kontrolují. Ovšem protože fronty čtení a zápisů mají dnes desítky položek, které se musí na konflikty zkontrolovat, začala být jako optimalizace výkonu použita i zde technika spekulativního vykonání operací. CPU tak připustí čtení s hypotézou, že nekoliduje s žádným zápisem, aby byla operace co nejrychleji dokončena. Podobně jako při predikci větvení je pak v případě, že se tento odhad ukáže jako chybný, dodatečně načtená hodnota zahozena a CPU začne znovu správně. Ovšem ono načtení předchozí hodnoty je podobně jako u chyby Spectre riziko, protože data už jsou v cache. Šikovný programátor si je tam může najít a dostat se k nim ve svém programu dostat, i když by správně neměl. A pokud se mu podaří takto „nasát“ nějakou citlivou adresu, stává se tato chyba bezpečnostním problémem.
Nebezpečnost této zranitelnosti byla skutečně prokázána a dostala tedy již zmíněné jméno „Speculative Store Bypass“ a označení CVE-2018-3639. Útok Speculative Store Bypass by neměl být schopen dostat se do paměti jádra, takže ohrožuje jen uživatelský prostor a aplikace, kde ale stále může dojít k získání citlivých dat útočníkem. Nejohroženější budou aplikace spouštějící cizí kód, u těch by tento útok mohl být použit pro čtení dat mimo sandbox. Podle Microsoftu by teoreticky mohly být ohrožené také servery používající virtualizaci či enklávy, kde by mohlo dojít k útoku mezi jednotlivými VM nebo na hypervizor.
Co je důležité: chyba vyžaduje spuštění kódu na cílovém počítači, útočník tedy buď musí být lokální uživatel (ovšem nepotřebuje zvýšená práva), nebo musí kód na počítač dostat jinak – například jako javascript na webové stránce nebo v reklamě zobrazované na ní, i když takovéto zneužití asi zatím výzkumníci nevyvinuli či nezveřejnili. Nejde každopádně o chybu zneužitelnou vzdáleně.

Zranitelnost má opět (skoro) všechno
Postiženy či teoreticky zranitelná jsou jako u Spectre pravděpodobně všechna či skoro všechna výkonnější CPU typu out-of-order, jelikož jde o obecně používanou techniku pro zvýšení výkonu. Intel například uvádí procesory od Nehalemu až po současnou osmou generace Core (Coffee Lake, Cannon Lake, Kaby Lake) a Skylake-X/SP, včetně Xeonů. Také Atomy jsou zranitelné, a to zřejmě architektury Goldmont (včetně serverového Denvertonu), Goldmont+, naopak Silvermont a Airmont snad ne, uvedené nejsou. U AMD by měly být postižena minimálně jádra od Bulldozeru až po Excavator i Zen. U ARMU pak chyba postihuje Cortexy A57, A72, A73 a A75, z 32bitových Cortexů pak A8, A9, A15 a A12/A17. Je pravděpodobné, že zranitelnost mají také vlastní jádra například Applu. Podle IBM by zřejmě měly být zranitelné i procesory Power včetně nejnovějších Power9. Další procesorové architektury budou patrně také zastoupeny, ale nebyly o nich informace v prvním sledu po odhalení chyb.

Řešení chyby
Řešení této chyby bude dvojí. Podobně jako u varianty 1 chyby Spectre by se měla použít různá opatření stěžující využití tohoto útoku v citlivých místech různého softwaru, který by mohl být zranitelný, tedy různé sandboxy, spouštění javascriptu v prohlížečích a podobně. V těchto aplikacích mohou být použité například serializující instrukce. Některá opatření proti Spectre v1 už by sama měla být účinná – například redukce přesnosti časovačů pro javasctript v prohlížečích webu.
Ztráty výkonu zatím nebudou
Druhou možností, které bude již na hardwarové úrovni, bude vypnutí spekulativního čtení v procesoru, což je označeno jako funkce SSBD (Speculative Store Bypass Disable). Její aktivace zakáže procesoru provádět citlivou optimalizaci I/O, ovšem je to za cenu ztráty výkonu, kterou Intel uvádí jako 4–8 %. Problém je, že v tomto případě by nebyla postižená jen systémová volání do jádra a změny kontextu jako u Spectre/Meltdown, ale veškeré vykonávání kódu, takže tento postih by byl pravděpodobně nepříjemnější. Protože by chyba měla být relativně náročnější k zneužití a momentálně není riziko vyhodnoceno jako tak vysoké, nebude proto v operačních systémech tato hardwarová ochrana SSBD ve výchozím stavu aktivní. Tato ochrana je nabízena jen jako volitelné opatření pro zvlášť citlivé či opatrné uživatele a výrobci CPU doporučují ji ponechat ve výchozím neaktivním stavu. Prozatím tedy bude použita jen první čistě softwarová ochrana spočívající v úpravách citlivého kódu, ovšem je samozřejmě možné, že v případě, že by se chyba ukázala jako nebezpečnější a začala se zneužívat, by mohlo dojít ke změně tohoto rozhodnutí.
SSBD by mělo být možné aktivovat pro jednotlivé procesy, naštěstí tedy nemusí být nastaveno úplně globálně. Tedy alespoň na platformě x86, u ARMu ale snad má jít o kompletní vypnutí funkce Memory Disambiguation při bootu, což zní docela drsně. K použití SSBD bude podobně jako v případě aktualizací proti chybě Spectre třeba nový mikrokód či firmware, tedy alespoň v případě Intelu a ARMu. Materiály AMD o něm nehovoří, je možné, že funkce zpřístupňující deaktivování spekulativního čtení (a tedy pro SSBD) tohoto typu jsou již přítomné. Podobně jako u Spectre nebudou tyto aktualizace samy o sobě automaticky ovlivňovat chod CPU (tedy ho zpomalovat), pouze zpřístupní infrastrukturu, pomocí níž bude ono zpomalovací ochranné opatření moci aktivovat operační systém.

Aktualizace, které umožní SSBD používat, by měly postupně vycházet v hlavních operačních systémech. Zatím to ale vypadá, že pro Windows ještě nejsou a také informace o vydáních Linuxu, v kterých by se měla objevit, jsem nenašel. Nové mikrokódy patrně ještě také chvíli potrvají, Intel je má údajně v beta fázi a jsou testované výrobci počítačů a desek. Ochrany prvního softwarového typu by měly být roztroušené v různých potenciálně citlivých programech (prohlížeče, virtualizační hypervizory), takže nemusí vyjít jako nějaká zvláštní vyhrazená aktualizace OS.
Čekal bych, že se s tímto typem zranitelností strhne trochu lavina. V dobách návrhů se o tomhle typů útoků zřejmě neuvažovalo (nedivím se) a jestli se teď začaly hledat, tak to může růst.
Docela by mě zajímalo, jak je to se zpomalením, zda se to nasčítává přes opravy, nebo ne.
PS: Opravte si „zranitlenosti“, „spouštějíví“ a „na na“
Díky za upozornění, opraveno.
Ten postřeh bude asi správný a podobných problémů asi vyvstane víc (nebo už vyvstává, ale obvykle je tam ta doba, kdy se to řeší pod NDA, takže my se to dozvíme až se zpožděním).
Výkonnostní postih by se měl skutečně sčítat (plus minus), protože tyhle opravy postihují různé separátní situace. Spectre/Meltdown zpomalují systémová volání nebo context switch, SSBD by v případě aktivace mělo vliv asi na jakýkoliv kód, pokud není mimořádně výpočetně intenzivní s malým vytížením load/store – což asi nebude moc častá věc mimo třeba stress testing.
Ono i to zodolňování prohlížečů, sandboxů a tak podobně také může udělat daný software trošku pomalejší, ale u softwaru je to normální věc – funkcionalita navíc a víc bezpečnostních opatření vede k nižšímu výkonu/větší zátěži hardware.
Ono obecně, novější software vždycky mívá vyšší nároky. Asi se s tím budeme muset smířit a chápat tyhle opravy/obcházení HW zranitelností jako další formu toho postupného zvyšování HW nároků softwaru/OS. Silnější bezpečnost, která je vzhledem k sofistikovanosti kyberzločinu/malwaru nutná, k tomu růstu režie holt bude teď přispívat víc než třeba dřív.
Kolik teda už máme výkonu dolů, 10-18% u Intelu? To se dostáváme s výkonem tak doby Nehalemu.
nedali ti najíst?
koho zajímají díry, které se ná týkají asi tak, jako že v Chile prší a Angláni budou mít víc avokáda?
co redmarx? ma zaktualizovano? 🙂
Kvalita, coskoro sa odstrania všetky uprady-vylepšenia a fintičky na zlepšovanie výkonu u x86 ….návrat 486ky 😀
docela by mě zajímalo, jakým způsobem se může potenciální útočník dostat k těmto dírám … všude člověk čte spoustu odborných termínů, ale že by někdo zjednodušeně napsal, jak to přesně funguje, to ne …
Sice v anglictine no celkom jednoducho na priklade:
https://www.youtube.com/watch?v=Uv6lDgcUAC0
vidíš, přesně o tomhle píši … znamená to tedy, že jsme všichni napadeni a lidově řečeno v prdeli …? Ne …
Já se neptal, jak ty díry fungují, ale jak se útočník může k těm dírám, ke zneužití dostat … přes flash, přes mail, přes router – modem … co musí udělat a co musíš udělat ty, aby se mu útok povedl … jaké k tomu potřebuje nástroje, co všechno musíš podělat ty sám, aby se mu útok povedl …
Vsechny varianty meltdown / spectre vyzaduji spusteni kodu na lokalnim stroji. Je lhostejne s jakymi pravy uzivatele.
Čili dokud uživatel není totální jitrnice, je v bezpečí.
Presne tak. Coz bohuzel nemeni nic na tom, ze totalnich jitrnic/BFU je drtiva vetsina.
no konečně, díky
Je to napsané v šestém odstavci. Lokální přístup, ale teoreticky taky javascript, kdy by kód mohl zmanipulovat JIT tak, aby zkomplikoval kód na potřebnou binárku. To ale snad teď nebude tak snadné, po těch opravách proti Spectre (javascript je teda obecně dost nešťastná věc, z pohledu bezpečnosti…)