Zespół badaczy z Vrije Universiteit Amsterdam odkrył coś nowego (CVE-2020-0543) w strukturach mikroarchitektonicznych procesorów Intel, wyróżniający się tym, że pozwala na przywrócenie wyników wykonania niektórych instrukcji wykonanych na innym rdzeniu procesora. Jest to pierwsza luka w mechanizmie wykonywania instrukcji spekulatywnych, która umożliwia wyciek danych pomiędzy poszczególnymi rdzeniami procesora (wcześniej wycieki ograniczały się do różnych wątków tego samego rdzenia). Badacze nazwali problem CROSSTalk, ale Luka ta nosi nazwę SRBDS (Special Register Buffer Data Sampling).
Podatność dotyczy rok temu do klasy problemów MDS (Microarchitectural Data Sampling) i opiera się na zastosowaniu metod analizy kanałów bocznych do danych w strukturach mikroarchitektonicznych. CROSSTalk jest bliski luki w zabezpieczeniach , ale różni się źródłem wycieku.
Nowa luka manipuluje wyciekiem wcześniej nieudokumentowanego bufora pośredniego, który jest współdzielony przez wszystkie rdzenie procesora.
polega na tym, że niektóre instrukcje mikroprocesora, w tym RDRAND, RDSEED i SGX EGETKEY, są implementowane przy użyciu wewnętrznej operacji mikroarchitektonicznej SRR (Special Register Reads). W przypadku procesorów, których to dotyczy, dane zwrócone w ramach SRR są przechowywane w buforze pośrednim wspólnym dla wszystkich rdzeni procesora, po czym są przesyłane do bufora wypełniającego powiązanego z konkretnym fizycznym rdzeniem procesora, na którym zainicjowano operację odczytu. Następnie wartość z bufora wypełniającego kopiowana jest do rejestrów widocznych dla aplikacji.
Rozmiar pośredniego bufora współdzielonego odpowiada linii pamięci podręcznej, która jest zwykle większa niż rozmiar odczytywanych danych, a różne odczyty wpływają na różne przesunięcia w buforze. Ponieważ bufor współdzielony jest kopiowany w całości do bufora wypełniającego, przenoszona jest nie tylko część potrzebna do bieżącej operacji, ale także dane pozostałe po innych operacjach, w tym wykonywanych na innych rdzeniach procesora.
Jeśli atak się powiedzie, lokalny użytkownik uwierzytelniony w systemie może określić wynik wykonania instrukcji RDRAND, RDSEED i EGETKEY w obcym procesie lub wewnątrz enklawy Intel SGX, niezależnie od rdzenia procesora, na którym wykonywany jest kod.
Naukowcy, którzy zidentyfikowali problem Prototypowy exploit demonstrujący możliwość wycieku informacji o losowych wartościach uzyskanych za pomocą instrukcji RDRAND i RDSEED w celu odzyskania klucza prywatnego ECDSA przetwarzanego w enklawie Intel SGX po wykonaniu tylko jednej operacji podpisu cyfrowego w systemie.
problem szeroka gama procesorów Intel do komputerów stacjonarnych, mobilnych i serwerowych, w tym Core i3, i5, i7, i9, m3, Celeron (seria J, G i N), Atom (seria C, E i X), Xeon (E3, E5, rodziny E7, W i D), Xeon Scalable itp. Warto zauważyć, że Intel został powiadomiony o luce we wrześniu 2018 r., a w lipcu 2019 r. udostępniono prototyp exploita demonstrującego wycieki danych pomiędzy rdzeniami procesora, jednak opracowanie poprawki zostało opóźnione ze względu na złożoność jej wdrożenia. Proponowana dzisiaj aktualizacja mikrokodu rozwiązuje ten problem, zmieniając zachowanie instrukcji RDRAND, RDSEED i EGETKEY w celu nadpisania danych we współdzielonym buforze, aby zapobiec osadzaniu się tam resztek informacji. Ponadto dostęp do bufora jest wstrzymywany do czasu odczytania i przepisania zawartości.
Skutkiem ubocznym tego typu ochrony są zwiększone opóźnienia podczas wykonywania poleceń RDRAND, RDSEED i EGETKEY oraz zmniejszona przepustowość podczas prób jednoczesnego wykonania tych instrukcji na różnych procesorach logicznych. Wykonanie poleceń RDRAND, RDSEED i EGETKEY wstrzymuje także dostęp do pamięci z innych procesorów logicznych. Funkcje te mogą negatywnie wpływać na wydajność niektórych aplikacji serwerowych, dlatego oprogramowanie sprzętowe udostępnia mechanizm (RNGDS_MITG_DIS) umożliwiający wyłączenie ochrony dla instrukcji RDRAND i RDSEED wykonywanych poza enklawą Intel SGX.
Źródło: opennet.ru