Opět bezpečnostní problém s procesory. Exploit TLBleed postihuje Hyper Threading

Moc dlouho neuplynulo od předchozích případů s chybami Lazy FP Restore a Speculative Store Bypass a u procesorů byl odhalen další bezpečnostní problém. Asi si na to budeme muset zvyknout. Nová chyba je výzkumníky pojmenovaná TLBleed a je rizikem pro kryptografické operace, neboť by mohla být zneužita k úniku klíčů a tedy kompromitování šifrování (až už online při návštěvě webových stránek a komunikaci, nebo offline u dat).

TLBleed se sice netýká spekulativního vykonávání instrukcí a nesouvisí tedy se Spectre, ale má s ostatními letošními dárečky společné to, že využívá tzv. timing attack. To znamená, že zjišťuje informace, které mělo CPU udržet v tajnosti z toho, jak dlouho trvá provádění operací nad nimi. To, že různé výpočty trvají v závislosti na předmětných datech nekonstantní dobu, je bohužel neodmyslitelná vlastnost současných CPU, takže podobné útoky hned tak vymýceny nebudou.

Timing útoky jsou už dlouhou dobu popsány coby metoda jak se dostat k částem nebo celým délkám šifrovacích klíčů, pokud můžete nějakým způsobem pozorovat běh programu, který s nimi pracuje. V případě chyby TLBleed je takovým pozorovatelem kód běžící na druhém vlákně procesoru, jenž používá HT nebo SMT. Z toho plyne aplikovatelnost tohoto exploitu: postihuje procesory s SMT/HT a k jeho využití musí útočník spustit na počítači kód na stejném jádře, na kterém (na druhém z vláken) běží kryptografická aplikace. Jde tedy primárně o lokální útok, kdy už útočník musí mít přístup k systému (například jako další uživatel serveru). Tento přístup ale nemusí být privilegovaný.

Riziko pro uživatele je naštěstí malé

Jako u předchozích chyb je zde riziko, že by se někomu podařilo útok implementovat v javascriptu a pak jej spouštět z webových stránek na počítačích návštěvníků. Tím by nebezpečnost vzrostla na vzdálený útok, ale to je asi zatím spíše teoretická možnost. Navíc by ji měly ztěžovat úpravy prohlížečů aplikované proti chybě Spectre. Zatím tedy asi platí, že ohrozit vás případně může jen program spuštěný lokálně ve vašem PC, takže pokud nespouštíte/neinstalujete nedůvěryhodné aplikace z internetu, měly byste být v bezpečí.

Princip útoku

TLBleed není úplně unikátní chyba, navazuje na podobné slabé místo, kterým byly timing útoky na kryptografii pomocí L1 cache. V těch šlo o to, že druhé vlákno pozorovalo, jak kryptografická knihovna na prvním vláknu používá cache, a z měření toho, jak se cache chová, dokázalo rekonstruovat, s jakými daty šifrovací algoritmus operuje. Výsledkem bylo, že škodlivý program na druhém vlákně dokázal pouze z monitorování výkonnostních charakteristik uhádnout šifrovací klíč.

TLBleed je podobný, ovšem místo L1 cache používá k špiclování jinou strukturu, kterou sdílí SMT/HT vlákna běžící na jednom vlákně: Translation Lookaside Buffer neboli TLB. To je de facto také paměť cache, která slouží ke cachování údajů o tom, kam je určitá stránka virtuální paměti namapována v paměti fyzické. Operační systém na počítači takto mapuje enormní množství stránek (virtuální paměť používají všechny moderní operační systémy) a data o tomto mapování jsou uložena v RAM. Protože přístup k této „mapě“ při každém požadavku na data z paměti by byl výkonnostně extrémně problematický, má CPU vyhrazenou integrovanou mezipaměť TLB, která si pamatuje mapování několika tisíc posledně použitých stránek a tato data jsou přístupná jen s krátkou latencí.

Bezpečnostní problém vyvstává z toho, že monitorováním TLB lze získat informaci o tom, zda kód běžící na jádře (zde na jeho druhém vláknu) pracuje s daty, jejichž stránky jsou pokryté obsahem TLB – tehdy trvá přístup do paměti jen pár cyklů – nebo za došlo k situaci „TLB Miss“ a informace o mapování se musí načíst z RAM, což trvá stovky cyklů. A stejně jako u podobného útoku na cache se tyto informace dají chytrou analýzou použít k uhádnutí šifrovacícho klíče. Že to funguje, dokázal Ben Gras z Univerzity Vrije v Amsterdamu, referát s podrobnostmi bude přednesen na konferenci Black Hat USA 2018 9. srpna.

Popis problému TLBleed v programu konference Black Hat USA 2018

Kryptografický klíč lze ukrást během jediného odposlechu

Exploit TLBkeed podle něj úspěšně dokázal zrekonstruovat 256bitový klíč z podpisového algoritmu Curve 25519 EdDSA implementovaného v libgcrypt, který byl zkompilován s ochranou proti timing útokům na L1 cache – ovšem proti tomuto útoku používajícímu TLB již tato ochrana nefungovala. K odhalení klíče údajně s 98,2% až 99,8% úspěšností stačí jen 2 ms dlouhé „pozorování“ jediného procesu podepisování na druhém vlákně jádra a analýza „odposlechu“ pak trvala 17 sekund (využito bylo předtrénované neuronové sítě a následně finálního útoku hrubou silou, na který už stačil zlomek sekundy).

Gras uvádí ještě další odvozený exploit, který dokáže zjišťovat bity klíčů také z implementací algoritmu RSA, které jsou také opatřené ochranami proti timing útokům. Ochrana šifrovacích knihoven bude proto kvůli TLBleed muset být asi hodně vylepšena, neboť i budoucí útoky budou na základě tohoto výzkumu zřejmě vylepšeny. Gras uvádí, že bude prezentovat informace architektuře a chování jednotlivých úrovní TLB na moderních procesorech Intel, což jsou informace, jež Intel nezveřejňuje a jejich zdokumentování také povede k snazšímu vymýšlení podobných nízkoúrovňových exploitů.

Nepropadejte panice

Naštěstí tento útok není reálně tak nebezpečný jako Spectre nebo Meltdown – přímo autor exploitu Ben Gras na Tweetu uklidňuje, že „nejde o další Spectre“. Kryptografické knihovny, které mají být bezpečné v rizikovém prostředí například na servech, které sdílí více uživatelů, budou muset být upraveny. Takové úpravy, které mají za cíl odstranit variabilní trvání výpočtů v závislosti na zpracovávaných datech, se již u těchto programů používají na jiných úrovních a po implementaci podobné kamufláže i v použití TLB by snad měl být problém odstraněn. Řešení bude tedy čistě softwarové. Nejde totiž o hardwarovou chybu v návrhu procesoru, ale prostě jen o zneužití podstaty fungování moderního CPU, které zde v pravém slova smyslu pracuje, jak má.

Je možné, že útok TLBleed funguje nyní jen na konkrétních architekturách procesorů Intel, pro který byl napsán (demonstrován byl na Skylake, Coffee Lake a Broadwellu-EP). Ovšem v principu by mělo být možné jej zacílit i na jiné architektury používající SMT – ať už Zen od AMD, IMB Power9, nebo jádra Vulcan v ARM procesorech Cavium ThunderX2 – pokud by byla reverzním inženýrstvím popsána architektura jejich TLB. Zdá se, že Intel nebude podnikat na opravu nějaké okamžité kroky, v oficiálním vyhlášení píše, že knihovny napsané tak, by jejich výpočty trvaly konstantní dobu, včetně jeho vlastních Intel Integrated Performance Primitives Cryptography version U3.1, by měly být proti útoku odolné. Nicméně to asi neplatí plně, protože jak už bylo řečeno, libgcrytp útoku podlehla.

Až na postupné změny v různých kryptografických modulech třetích stran tak asi ale TLBleed nyní nepovede k nějakém masivnímu patchování jako v případě Spectre a Meltdownu. AMD uvedlo webu The Register, že zatím neodhalilo, že by některé z jeho procesorů byly exploitem TLBleed zranitelné, to ale může být proto, že je zaměřen na architekturu typickou pro Intel, po úpravách by si tento útok fungovat mohl.

Based on our analysis to date we have not identified any AMD products that are vulnerable to the TLBleed side channel attack identified by the researcher. Security remains a top priority and we will continue to work to identify any potential risks for our customers and, if needed, potential mitigations.

OpenBSD v reakci zakazuje Hyper Threading

Výjimkou z této klidné reakce je zřejmě zatím jen systém OpenBSD. Ten již před veřejným odhalením informací o TLBleed předběžně aplikoval patch, který kompletně deaktivuje HT na procesorech Intel právě z obavy před útoky typu TLBleed. To vyvolalo značné pozdvižení a obavy, ale podle přesnějších informací, které poté byly o útoku sděleny, asi nejde o adekvátní odpověď. Výkonnostní dopad zakázání HT (přičemž OpenBSD údajně uvažuje o rozšíření tohoto zákazu i na ostatní SMT architektury) je masivní, vícevláknové aplikace by utrpěly ztrátu výkonu v desítkách procent. Nicméně do budoucna by mělo být možné například upravit scheduler tak, aby na vláknech jednoho jádra nespouštěl procesy patřících různým uživatelům, což by tyto útoky ztížilo bez vypnutí SMT.

Pro kontext je ale asi dobré připomenout, že HT/SMT je úplně stejným rizikem z hlediska zmíněných předchozích útoků, které místo TLB zneužívaly běžné paměti cache. V jejich případě ale k zakazování SMT nedošlo a místo toho se prostě ošetřily kryptografické knihovny (ono lze asi tvrdit, že problém vyvstává z jejich implementace). Tudíž i nyní se zdá adekvátní k tomuto drastickému opatření nepřistoupit.