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
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.

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