Grupa badawcza z Vrije Universiteit Amsterdam odkryła nową (CVE-2020-0543) w mikroarchitekturach procesorów Intel, zauważalną tym, że pozwala na odzyskanie wyników wykonania niektórych instrukcji realizowanych na innym rdzeniu CPU. To pierwsza podatność w mechanizmie spekulacyjnego wykonywania instrukcji, która umożliwia wyciek danych między oddzielnymi rdzeniami CPU (wcześniejsze wycieki ograniczały się do różnych wątków jednego rdzenia). Badacze nazwali tę problematykę CROSSTalk, ale w podatność ta jest wymieniana jako SRBDS (Special Register Buffer Data Sampling).
Podatność odnosi się do rok temu klasy problemów MDS (Microarchitectural Data Sampling) i bazuje na zastosowaniu metod analizy przez kanały boczne w danych w mikroarchitekturach. CROSSTalk jest bliskie podatności , ale różni się źródłem wycieku.
Nowa podatność manipuluje wyciekiem z wcześniej nieudokumentowanego bufora pośredniego, który jest używany wspólnie przez wszystkie rdzenie CPU.
w tym, że niektóre instrukcje mikroprocesora, w tym RDRAND, RDSEED i SGX EGETKEY, są realizowane przy użyciu wewnętrznej mikroarchitektonicznej operacji SRR (Special Register Reads). Na podatnych na tę podatność procesorach dane zwracane dla SRR osiadają w wspólnym buforze pośrednim dla wszystkich rdzeni CPU, a następnie są przesyłane do bufora wypełnienia, związanego z konkretnym fizycznym rdzeniem CPU, na którym została zainicjowana operacja odczytu. Następnie z bufora wypełnienia wartość jest kopiowana do rejestrów widocznych dla aplikacji.
Rozmiar wspólnego bufora pośredniego odpowiada linii cache, co zazwyczaj jest większe niż rozmiar odczytywanych danych, a różne operacje odczytu dotyczą różnych przesunięć w buforze. Ponieważ wspólny bufor jest kopiowany do bufora wypełnienia w całości, to przenosi się nie tylko potrzebna do bieżącej operacji porcja, ale także dane pozostałe z realizacji innych operacji, w tym tych wykonywanych na innych rdzeniach CPU.
W przypadku udanej organizacji ataku, uwierzytelniony lokalny użytkownik systemu może określić wynik wykonania instrukcji RDRAND, RDSEED i EGETKEY w cudzym procesie lub wewnątrz enklawego Intel SGX, niezależnie od rdzenia CPU, na którym wykonywany jest kod.
Badacze, którzy zidentyfikowali problem Prototyp exploita, który demonstruje możliwość wycieku danych o losowych wartościach uzyskiwanych za pomocą instrukcji RDRAND i RDSEED, w celu odzyskania klucza prywatnego ECDSA, przetwarzanego w enclave Intel SGX, po przeprowadzeniu w systemie zaledwie jednej operacji z podpisem cyfrowym.
Problem szeroka gama procesorów Intel dla komputerów stacjonarnych, mobilnych i serwerowych, w tym Core i3, i5, i7, i9, m3, Celeron (linie J, G i N), Atom (linie C, E i X), Xeon (rodziny E3, E5, E7, W i D), Xeon Scalable itd. Zauważalne jest, że firma Intel została poinformowana o podatności we wrześniu 2018 roku, a w lipcu 2019 roku przedstawiono prototyp exploita demonstrującego wyciek danych między rdzeniami CPU, jednak opracowanie poprawki opóźniło się z powodu złożoności jej wdrożenia. W dzisiejszej proponowanej aktualizacji mikrokodu problem został zablokowany poprzez zmianę zachowania instrukcji RDRAND, RDSEED i EGETKEY na nadmiarowe nadpisywanie danych w wspólnym buforze, aby zapobiec osadzaniu się w nim pozostałych informacji. Ponadto zastosowano wstrzymanie dostępu do bufora do zakończenia operacji odczytu i nadpisania zawartości.
Skutkiem ubocznym takiej ochrony jest zwiększenie opóźnień przy wykonywaniu RDRAND, RDSEED i EGETKEY oraz zmniejszenie przepustowości podczas próby jednoczesnego wykonywania tych instrukcji na różnych logicznych procesorach. Wykonanie RDRAND, RDSEED i EGETKEY również wstrzymuje dostęp do pamięci z innych logicznych procesorów. Te cechy mogą negatywnie wpłynąć na wydajność niektórych aplikacji serwerowych, dlatego w oprogramowaniu znajduje się mechanizm (RNGDS_MITG_DIS) do wyłączenia ochrony instrukcji RDRAND i RDSEED wykonywanych poza enclave Intel SGX.
Źródło: opennet.ru
