BTR: nowa luka Spectre v2 atakuje Linux

BTR: nowa twarz Spectre v2

Badacze z dwóch ośrodków akademickich opisali nowy wariant ataku Spectre v2, nazwany Branch Target Reuse (BTR). Luka dotyczy środowisk, w których działa JIT (Just-In-Time) — m.in. silników przeglądarek, runtime’ów językowych oraz komponentów jądra Linuksa. W praktyce oznacza to, że problem może pojawić się zarówno w aplikacjach webowych, jak i w systemowym kodzie korzystającym z JIT.

Najbardziej niepokojące jest to, że BTR pozwala wykorzystać stare wpisy w Branch Target Buffer (BTB), czyli w pamięci predykcji skoków procesora. Gdy kod JIT zostaje zwolniony, a później w tym samym miejscu pojawia się nowy fragment, procesor może nadal „pamiętać” poprzedni cel skoku. To tworzy warunki do spekulatywnego wykonania kodu w niewłaściwym miejscu i do wycieku danych przez cache side channel.

Jak działa atak

BTR bazuje na połączeniu dwóch zjawisk:

• self-modifying code lub kodu JIT, który zmienia się w czasie,
• predykcji indirect branch, czyli pośrednich skoków w procesorze.

Schemat ataku jest prosty w założeniu, choć trudny technicznie:

1. atakujący uruchamia kod w silniku JIT,
2. „uczy” predyktor procesora określonego skoku,
3. wymusza zwolnienie wcześniej użytego bloku kodu,
4. alokuje nowy blok w podobnym miejscu pamięci,
5. ponownie wyzwala skok, a CPU korzysta ze starego wpisu BTB,
6. dochodzi do spekulatywnego wykonania i ujawnienia informacji.

W efekcie atak nie musi bezpośrednio czytać pamięci. Zamiast tego odczytuje dane pośrednio, analizując ślady pozostawione w cache procesora.

Wyciek hasha root w kilka minut

Najmocniejszym elementem demonstracji były ataki pokazane na jądrze Linuksa. W przygotowanych scenariuszach udało się odzyskać hash hasła root z w pełni załatanej maszyny z procesorem Intel i domyślnymi zabezpieczeniami.

Według opisu badaczy zajęło to od 3 do 5 minut, zależnie od generacji rdzenia Intel. Atak nie ujawnia hasła wprost, ale przechwytuje jego hash — a to i tak poważny problem, bo taki zapis można potem próbować łamać offline.

Do demonstracji wykorzystano sytuację, w której użytkownik uruchamia su root, co ładuje hash do pamięci. Następnie atakujący lokalizuje odpowiedni proces i zawęża poszukiwania do jego przestrzeni pamięci. Tempo wycieku wynosiło około 8 bajtów na sekundę.

Kogo dotyczy problem

BTR został przetestowany na kilku popularnych środowiskach:

• SpiderMonkey z Firefoksa,
• GraalVM,
• cBPF JIT w jądrze Linuksa.

Wszystkie okazały się podatne, choć stopień wykorzystania był różny. Największe znaczenie praktyczne ma jednak Linux, ponieważ jego jądro korzysta z JIT w niektórych scenariuszach i może stać się celem lokalnego ataku po uzyskaniu możliwości uruchomienia kodu bez uprawnień administratora.

Obejście części zabezpieczeń

Badacze zwracają uwagę, że BTR podważa część istniejących mitigacji dla Spectre v2, w tym podejścia oparte na Training Solo. Problem ma charakter „czasowy”: nie chodzi o przejęcie innego celu skoku, lecz o to, że ten sam skok po czasie prowadzi już do innego kodu.

To ważna zmiana w myśleniu o Spectre. Dotychczas wiele obron opierało się na założeniu, że atakujący musi przestawić skok na „inny” cel. BTR pokazuje, że wystarczy zmiana znaczenia kodu pod tym samym adresem.

Co z poprawkami

Po odpowiedzialnym ujawnieniu problemu przygotowano łaty dla jądra Linuksa. Związane z BTR identyfikatory to:

• CVE-2026-64507
• CVE-2026-64508

Według dostępnych informacji poprawki trafiły już do Linuksa. Obejmują one m.in. uruchamianie IBPB (Indirect Branch Predictor Barrier) w określonych sytuacjach, gdy dochodzi do ponownego użycia obszaru wcześniej wykonywanego przez cBPF.

W przypadku innych środowisk przyjęto różne strategie:

• GraalVM ogranicza ponowne użycie regionów przez losowanie lokalizacji cache kodu JIT,
• Mozilla rozważała mechanizmy oparte na IBPB, ale priorytetem pozostało pełne wdrożenie site isolation.

Co to oznacza dla użytkowników i administratorów

Najważniejszy wniosek jest prosty: lokalne uruchomienie nieuprzywilejowanego kodu na podatnym systemie może wystarczyć do wycieku danych z jądra. Atak nie jest zdalny, ale w środowiskach wieloużytkownikowych, kontenerowych i serwerowych wciąż ma znaczenie.

W praktyce warto sprawdzić, czy system korzysta z jąder objętych poprawkami oraz czy włączone są odpowiednie mechanizmy hardeningu dla BPF i JIT. BTR pokazuje też szerszy problem: współczesne procesory nie odświeżają całego stanu mikroarchitektonicznego po zmianie kodu, a to pozostawia przestrzeń dla kolejnych wariantów ataków Spectre.

Szerszy kontekst

Opis BTR pojawił się niedługo po innym badaniu dotyczącym spekulacyjnego wykonania, które także pozwalało omijać obronę przed Spectre v2 i wyciekać pamięć jądra na systemach Intel i AMD. To kolejny sygnał, że klasa ataków opartych na spekulacji wciąż nie została definitywnie zamknięta.

Dla zespołów bezpieczeństwa to przypomnienie, że ochrona przed Spectre nie sprowadza się do jednej łatki. Potrzebne są zarówno poprawki w jądrze, jak i ostrożność przy projektowaniu oraz wdrażaniu JIT-ów, które korzystają z pamięci współdzielonej i dynamicznie generowanego kodu.