S novou variantou Spectre v2 vytáhli výzkumníci hash rootova hesla za pět minut

Skupina VUSec z Vrije Universiteit Amsterdam zveřejnila 29. září útok Branch Target Reuse, zkráceně BTR. Je to další varianta Spectre v2, jenže míří na překladače JIT, tedy na programy, které si strojový kód vyrábějí až za běhu a zase ho zahazují. Rozcházení prediktoru se skutečným obsahem paměti autoři potvrdili na všech pěti počítačích, které vyzkoušeli.

Kód zmizí, záznam v prediktoru zůstane

Procesor předvídá, kam povede nepřímý skok, aby nemusel čekat na výsledek. Odhad si ukládá do vyrovnávací paměti cílů skoků (BTB). Když program vzápětí přepíše sám sebe, procesor se postará o to, aby se stará verze kódu už doopravdy nevykonala. Záznam v prediktoru ale nesmaže.

Běžnému programu to nevadí, protože jeho kód se nemění. Překladač JIT je jiný případ: drží si vyrovnávací paměť přeloženého kódu, kousky do ní sype a zase je uvolňuje, a nový kód sedne na tutéž adresu jako ten smazaný. Prediktor pak pošle spekulativní výpočet na vstupní bod, který tam už není, a trefí se doprostřed nově vygenerovaných instrukcí. Autoři to popisují jako spekulativní obdobu použití paměti po uvolnění.

Útočníkovi to dá dvě věci naráz. Může přeskočit pojistky, které překladač do kódu vkládá právě proti Spectre, a může skočit mezi instrukce místo na jejich začátek, takže se z těch samých bajtů stane jiný program.

Na jádro Linuxu stačí filtr seccomp

Nejdál se autoři dostali u cBPF, staršího filtrovacího jazyka v jádře Linuxu. Ten totiž smí přeložit i nepřivilegovaný program, na rozdíl od mocnějšího eBPF: používá ho seccomp, filtrování paketů v socketech a přes ně i Docker nebo Chrome.

Postup je prostý. Útočník nainstaluje jeden filtr jako trénovací, nechá ho proběhnout, odstraní ho a na totéž místo dá filtr druhý, jehož čtyřbajtové konstanty tvoří hledanou posloupnost instrukcí. Zastaralý záznam v prediktoru pořád ukazuje na vstupní bod toho prvního, takže spekulace skočí doprostřed konstant druhého.

Samé znovupoužití paměti vyšlo při měření na odhadovanou rychlost úniku 5,7 kB za sekundu na jádrech Raptor Cove a 5,4 kB na Lion Cove. Hotový exploit na předem sestaveném jádře Ubuntu 24.04 ve verzi 6.14.0-27 je pomalejší, protože si musí sáhnout na konkrétní hodnotu v paměti: 8 bajtů za sekundu. I to stačí, když se neleze celou pamětí, ale skáče se po ukazatelích. Druhá verze exploitu obejde i konstantní zaslepení, obranu, kterou jádro zapíná volbou bpf_jit_harden a která je ve výchozím nastavení vypnutá, a hash rootova hesla z procesu su najde na obou procesorech do pěti minut.

Prohlížeč a virtuální stroj Javy dopadly jinak

Druhé dvě prostředí se ukázala jako odolnější, a rozhoduje o tom úklid paměti. V SpiderMonkey, tedy v enginu JavaScriptu a WebAssembly ve Firefoxu, se dá skočit rovnou do tabulky konstant uvnitř spustitelné paměti. Na Intelu z toho vyšlo 36 bajtů za sekundu u Raptor Cove a 62 u Lion Cove, kdežto na Ryzenu 9 7950X, na Cortexu A76 v Raspberry Pi 5 a na Cortexu X3 v čipu Tensor G3 nepřežil reorganizaci paměti ani jeden záznam. Hotový útok z prohlížeče by navíc potřeboval ještě způsob, jak obejít hrubé časovače, takže zůstalo u důkazu proveditelnosti.

U GraalVM, kde má být kód hosta uzavřený v maskované oblasti paměti, se BTR přes maskovací instrukci opravdu přenese a čtení sáhne ven. Jenže překlad a úklid paměti samotného GraalVM smažou záznam v prediktoru dřív, než se dá použít, takže naměřená rychlost úniku byla nula. Autoři to nepovažují za zásadní překážku a odhadují, že lepší načasování by mezeru zavřelo.

Výrobci chtěli nejdřív vidět exploit

Zajímavější než technika je způsob, jakým se oprava prosazovala. VUSec popsal problém Intelu, AMD, Armu a bezpečnostnímu týmu jádra Linuxu už v dubnu 2025. Podle vlastního popisu v etické části studie ho všichni uznali a uvalili na něj embargo, ale chtěli hotový exploit, aby bylo čím obhájit nasazení drahých obran. Autoři tedy napsali ty dva exploity, doplnili rozbor dalších enginů a v květnu 2026 to poslali znovu. Teprve pak se opravovalo.

Výrobci procesorů odkázali na to, že nástroje na obranu existují a patří do softwaru. V jádře Linuxu přibyla pro x86 pojistka, která při opětovném použití paměti po programu cBPF nebo eBPF vyvolá na všech jádrech bariéru prediktoru nepřímých skoků (IBPB) a takové znovupoužití rovnou odrazuje. Nese čísla CVE-2026-64507 a CVE-2026-64508, zapsaná 25. července. Chyba se týká jader od 5.18 výš; opraveno je 7.2 a zpětně 6.1.183, 6.6.145, 6.12.97, 6.18.39 a 7.1.4. Kdo aktualizuje, má to tedy dávno za sebou.

Oracle to u GraalVM vzal jinak a nechal adresy vyrovnávací paměti přeloženého kódu losovat; změna se do repozitáře dostala 19. srpna. Mozilla podle VUSecu možnost bariéry IBPB zvažovala, ale dala přednost dokončení izolace webů do vlastních procesů (site isolation), kterou Firefox zatím nemá nasazenou celou.

Proč to jedním záplatováním neskončí

Ochrana proti skokům na cizí cíl v procesoru existuje: na x86 se jmenuje IBT, na Armu BTI a obojí žádá, aby cíl nepřímého skoku začínal zvláštní instrukcí. Autoři zjistili, že Lion Cove je první generace Intelu, u které se před tou kontrolou nestihne spekulativně provést žádná instrukce; na Raptor Cove se stihne jedna a to stačí. A i tam, kde je kontrola těsná, jde ji obejít, pokud se ta zvláštní instrukce dá zapsat do generovaného kódu jako konstanta.

Podle nás je na tom nepříjemné hlavně to, že se opravuje následek, ne příčina. Prediktor a skutečný obsah paměti se v dnešních procesorech rozcházejí a hardware nemá jak je srovnat; obrany proto musí přidávat software, který kód generuje. BTR našel tři takové programy a jeden z nich byl vedle v jádře. Studie vychází v listopadu na konferenci ACM CCS v Haagu.

Zdroje

Popis útoku, ukázka úniku hashe a přehled nasazených obran jsou na stránce projektu BTR u skupiny VUSec, naměřené hodnoty a etická část ve studii pro konferenci CCS 2026 (PDF); kód je v repozitáři vusec/btr. Znění obou oprav jádra, dotčené verze a data zápisu vede registr CVE, změnu v GraalVM pull request oracle/graal#14261. O zrušení embarga psal Phoronix.