Sekurak Cyberstarter 2025 już 15 maja! 6 ścieżek, 40+ prelekcji

Nowe luki w procesorach Intel: powrót do problemów Spectre i Meltdown w nowej odsłonie

16 maja 2025, 14:13 | W biegu | 0 komentarzy

Nowe luki w procesorach Intel umożliwiające wycieki pamięci i ataki Spectre v2 zostały ujawnione przez badaczy z ETH Zürich i Vrije Universiteit Amsterdam. Odkrycia te pokazują, że pomimo siedmiu lat od ujawnienia podatności Spectre i Meltdown, problemy związane ze spekulacyjnym wykonaniem instrukcji wciąż stanowią poważne zagrożenie.

Badacze zidentyfikowali trzy kluczowe luki, a podatności nazwano Branch Privilege Injection i Training Solo.

CVE-2024-45332 (BPI – Branch Privilege Injection) – wykorzystuje warunki wyścigu Race Condition, pozwalając na wstrzyknięcie błędnych prognoz z uprawnieniami kernelowymi. Atak umożliwia przełamanie izolacji między procesami użytkownika a jądrem systemu.

CVE-2024-28956 (ITS – Indirect Target Selection) – dotyczy błędów w selekcji, wpływając na procesory Intel Core 9–11 generacji i serwery Xeon 2–3 generacji.

CVE-2025-24495 (Lion Cove BPU) – związana z problemem implementacji w architekturze Lion Cove.

Atak Training Solo pozwala na spekulacyjne przejęcie kontroli nad przepływem instrukcji w obrębie tej samej domeny (np. jądra), omijając zabezpieczenia wprowadzone po Spectre v2.

Na czym polega BPRC?

Jak czytamy w oficjalnej publikacji ETH, BPRC to klasa błędów wynikających z asynchroniczności operacji predyktora gałęzi w procesorach Intel. Okazuje się, że aktualizacje predyktora (np. Branch Target Buffer – BTB) nie są zsynchronizowane z przełączaniem kontekstu uprawnień (np. przejściem z trybu użytkownika do jądra), co prowadzi do warunków Race Condition. W efekcie możliwe jest wstrzyknięcie predykcji gałęzi z nieprawidłowym tagiem uprawnień – np. predykcja nauczona w trybie użytkownika może być użyta w trybie jądra. Badacze opisali trzy główne warianty:

BPRCU -> K – czyli naruszenie granicy user -> jądro.

BPRCG -> H – czyli naruszenie granicy guest -> hipervisor.

BPRCIPBPB – obejście bariery IBPB.

Na listingu 1 przedstawiono wyzwalacz dla warunku bufora RSB (undeflow) poprzez ciągłe powtarzanie instrukcji RET bez opowiadających wywołań call.

%rep 32
lea r8, qword ptr [rip + 0x3]
push r8
ret
%endrep

Jak działa nowy mechanizm BPI?

BPI to nowy mechanizm ataku, który pozwala precyzyjnie wstrzyknąć predykcję gałęzi oznaczoną jako kernel-mode z poziomu procesu użytkownika. Atakujący wykorzystuje warunek Race Condition pomiędzy wykonaniem instrukcji zmiany uprawnień (np. syscall) a aktualizacją BTB. W praktyce umożliwia to wyciek dowolnej pamięci jądra – nawet na w pełni załatanych, współczesnych systemach Linux z włączonymi wszystkimi zabezpieczeniami, jak przedstawiono na listingu 2.

static long __keyctl_read_key(struct key *key,
char *buffer, size_t buflen)
{
long ret;
down_read(&key->sem);
ret = key_validate(key);
if (ret == 0)
ret = key->type->read(key, buffer, buflen);
up_read(&key->sem);
return ret;
}

Jak można zauważyć w powyższym kodzie, keyctl wywołuje funkcję read. Funkcja wywołująca zostaje wbudowana, w wyniku czego rejestry r13 (wskaźnik na bufor) oraz r12 (długość bufora) trafiają pod kontrolę atakującego.

Rys. 1. Schemat przykładu Race Condition podczas przełączania uprawnień.

Nawiązanie do Spectre i Meltdown

Podatności Spectre (CVE-2017-5753 i CVE-2017-5715) oraz Meltdown (CVE-2017-5754) ujawnione w 2018 roku. Wykorzystywały one spekulacyjne wykonanie instrukcji do wycieku danych z pamięci, a także błędy w izolacji pamięci między procesami użytkownika, a jądrem (Meltdown).

Nowe luki, takie jak BPI, są ewolucją tych mechanizmów – omijają wprowadzone wcześniej poprawki (np. eIBRS w Spectre v2) poprzez manipulację stanem predyktorów podczas zmiany poziomów uprawnień.

Wpływ i zalecenia

Ataki typu BPI umożliwiają wyciek danych między maszynami wirtualnymi a hipernadzorcą. Użytkownicy mogą stać się celem ataków phishingowych wykorzystujących te luki? Prawdopodobnie tak, przy zaistnieniu warunków korzystnych.

Intel wydał już mikro poprawki, ale pełna migracja w środowiskach produkcyjnych może potrwać miesiące. Zaleca się natychmiastową aplikację aktualizacji firmware i monitorowanie zaleceń producentów dotyczących konfiguracji bezpieczeństwa (np. wyłączenie cBPF w przypadku AMD).

Mimo dekady walki z konsekwencjami ataków na procesory, nowe warianty wciąż powstają. Pokazuje to, że zabezpieczenia sprzętowe muszą ewoluować w kierunku pełnej izolacji stanu mikroarchitektury między procesami.

~Tomek Turba

Spodobał Ci się wpis? Podziel się nim ze znajomymi:



Komentarze

Odpowiedz