TONTOU: przerwanie w mikroskopijnym oknie omija ochronę Spectre v2

Zabezpieczenia przed Spectre v2 zakładają, że procesor neutralizuje stan predykcji rozgałęzień przed wejściem w kod, którego nie wolno spekulacyjnie przekierować. Badacze z MIT pokazali jednak, że między neutralizacją a użyciem mechanizmu pozostaje krótki odcinek instrukcji. Klasa TONTOU — Time-of-Neutralization to Time-of-Use — wykorzystuje właśnie tę szczelinę.

W wariancie Interrupt Injection napastnik doprowadza do obsługi przerwania w precyzyjnie wybranym momencie. Kod wykonany po czyszczeniu predyktora, ale przed chronioną gałęzią, może ponownie przygotować jego stan. W demonstracji umożliwiło to obejście wdrożonych mechanizmów Spectre v2 i odtworzenie danych z pamięci kernela Linuksa.

Dlaczego to nie jest zwykły TOCTOU

Klasyczny time-of-check to time-of-use dotyczy zmiany obiektu między sprawdzeniem a użyciem. TONTOU dotyczy stanu mikroarchitektury: zabezpieczenie „zeruje” lub izoluje predyktor, ale nie może jednocześnie zatrzymać wszystkich zdarzeń, które zajdą przed kolejnym skokiem pośrednim. Atakujący wykorzystuje asynchroniczne przerwanie jako kontrolowany wtrysk pracy do tego okna.

Publikacja TONTOU w USENIX Security 2026 opisuje metodę pomiaru takich okien i warunki ich eksploatacji. Kluczowa obserwacja brzmi: bezpieczeństwo zależy nie tylko od obecności IBRS, retpoline lub operacji czyszczącej, ale też od tego, co może wykonać się pomiędzy ochroną a pierwszym użyciem chronionego zasobu.

Kanał boczny nadal wymaga od atakującego lokalnej możliwości wykonywania kodu i wielu powtórzeń. Nie jest to zdalny odczyt całego kernela jednym pakietem. Jednak chmury wielotenantowe, przeglądarki, platformy CI i hosty uruchamiające nieufny kod są środowiskami, w których taki warunek ma znaczenie.

Co zostało pokazane

Badacze zademonstrowali ponowne trenowanie predyktora w „cieniu” ochrony oraz wyciek informacji pomimo aktywnych łagodzeń Spectre v2. Jako czytelny dowód użyli hashy haseł dostępnych w pamięci kernela. To potwierdza wpływ na poufność, ale nie oznacza, że dowolny proces natychmiast pozyska każdy sekret.

Ryzyko zależy od mikroarchitektury procesora, wersji kernela, zastosowanych mitigacji, możliwości generowania i synchronizacji przerwań oraz jakości gadżetu spekulacyjnego. Inwentaryzacja musi więc łączyć model CPU, microcode, kernel i typ workloadu.

Plan obrony

1. Śledź komunikaty producenta procesora i dystrybucji Linuksa oraz instaluj microcode i aktualizacje kernela jako jeden zestaw.
2. Ogranicz uruchamianie nieufnego kodu na hostach współdzielących wrażliwe workloady; osobny tenant nie oznacza osobnej mikroarchitektury.
3. Wyłącz niepotrzebne mechanizmy udostępniające precyzyjne timery i liczniki wydajności użytkownikom bez uprawnień.
4. Rozdziel domeny zaufania na osobne hosty fizyczne tam, gdzie przetwarzane są sekrety wysokiej wartości.
5. Weryfikuj faktyczny stan mitigacji z poziomu systemu, zamiast opierać się wyłącznie na deklaracji obrazu bazowego.
6. Uwzględnij ataki spekulacyjne w threat modelu sandboxów, runnerów CI, funkcji serverless i usług uruchamiających kod klienta.
7. Nie szukaj klasycznych IOC sieciowych: ważniejsze są ekspozycja lokalnego wykonania, nietypowe obciążenie, częste próbkowanie i możliwość współdzielenia rdzenia.

Walidacja poprawki musi mierzyć zachowanie CPU

Inwentaryzacja pakietów nie wystarcza dla błędów mikroarchitektonicznych. Efektywna ochrona jest kombinacją modelu procesora, wersji mikrokodu, kernela, hypervisora i flag uruchomieniowych. Ten sam obraz systemu może zachowywać się inaczej po migracji VM na host z inną generacją CPU. Zespół platformowy powinien zapisywać te parametry przy każdym węźle i wiązać je z klasami workloadów.

Testy regresyjne warto wykonywać na własnym sprzęcie z kontrolowanym kodem pomiarowym, bez odtwarzania ataku na systemach osób trzecich. Należy sprawdzać, czy przerwania i przełączenia kontekstu nie przywracają predyktora do stanu dostępnego dla innej domeny zaufania. Performance counters, nietypowa częstotliwość preempcji i korelacja z testami cache mogą pomóc w badaniu, ale zwykle nie są jednoznacznym IOC. Dlatego najważniejsze pozostają patching i separacja tenantów o różnych poziomach zaufania.

Fakty a wnioski Breachroad

Praca badawcza potwierdza nową prymitywę i kontrolowane demonstracje na wskazanych konfiguracjach. Nie potwierdza masowych ataków ani podatności każdego procesora. Rekomendacja fizycznego rozdzielenia najbardziej wrażliwych workloadów jest wnioskiem obronnym wynikającym z ograniczeń detekcji kanałów bocznych.

Szkolenia dla administratorów i zespołów chmurowych powinny łączyć aktualizacje z modelem współdzielenia sprzętu. Audyt bezpieczeństwa chmury może zweryfikować placement, hosty wykonujące nieufny kod i dowody aktywnych mitigacji.