Po prostu Intel nadal jest celem różnych luk w zabezpieczeniach które prowadzą do wycieku danych i dużo o nich mówiliśmy tutaj na blogu iw tym nowym Intel nadal nie jest wyjątkiem.
I zespół naukowców z Wolnego Uniwersytetu w Amsterdamie ha zidentyfikował nową lukę (CVE-2020-0543) w strukturach mikroarchitektury procesorów Intela, co jest godne uwagi z tego powodu umożliwia przywrócenie wyników niektórych instrukcji działać na innym rdzeniu procesora.
To jest pierwsza luka w zabezpieczeniach mechanizmu spekulacyjnego wykonywania instrukcji, umożliwiając wyciek danych między oddzielnymi rdzeniami procesora (Wcześniej wycieki ograniczały się do różnych wątków jądra).
Naukowcy nazwali ten problem CROSSTalk, ale dokumentacja firmy Intel określa tę lukę jako SRBDS (Przykładowe dane bufora rejestru specjalnego).
O CROSSTalk
Luka należy do klasy problemów związanych z MDS, wprowadzonych rok temu, oraz opiera się na zastosowaniu metod analizy firm trzecich do danych w strukturach mikroarchitektury.
Zasada CROSSTalk jest blisko luki w zabezpieczeniach RIDL, ale różni się źródłem wycieku. Nowa luka manipuluje pośrednim wyciekiem bufora wcześniej nieudokumentowane który jest współdzielony przez wszystkie rdzenie procesora.
Istota problemu polega na tym, że niektóre instrukcje mikroprocesora, w tym RDRAND, RDSEED i SGX EGETKEY, są implementowane przy użyciu operacji wewnętrznej mikroarchitektury SRR (Special Register Reads).
W podatnych procesorach dane zwrócone do SRR są umieszczane w buforze pośrednim wspólnym dla wszystkich rdzeni procesora, po czym są przesyłane do buforu populacji związanego z określonym rdzeniem fizycznym procesora, na którym rozpoczyna się operacja uruchamiania. Następnie z bufora wypełniającego wartość jest kopiowana do rejestrów widocznych dla aplikacji.
Rozmiar pośredniego bufora współdzielonego odpowiada linii pamięci podręcznejŻe jest zwykle większy niż rozmiar odczytanych danych a różne operacje odczytu wpływają na różne przesunięcia w buforze.
Ponieważ współużytkowany bufor jest kopiowany do całego bufora wypełniania, przenoszona jest nie tylko część wymagana do bieżącej operacji, ale także pozostałe dane z innych operacji, w tym wykonywanych na innych rdzeniach procesora.
Jeśli atak zostanie zorganizowany pomyślnie, użytkownik lokalny uwierzytelniony w systemie może określić wynik wykonanie instrukcji RDRAND, RDSEED i EGETKEY w dziwnym procesie lub w enklawie Intel SGX, niezależnie od rdzenia procesora, na którym działa kod.
Naukowcy kto odkrył problem opublikował prototyp exploita, który wykazał możliwość wycieku informacji na losowych wartościach uzyskanych za pomocą instrukcji RDRAND i RDSEED w celu przywrócenia klucza prywatnego ECDSA przetwarzanego w enklawie Intel SGX po wykonaniu tylko jednej podpisanej cyfrowo operacji w systemie.
To pokazało, że szeroka gama procesorów Intel do komputerów stacjonarnych, mobilnych i serwerowych, w tym Core i3, i5, i7, i9, m3, Celeron, Atom, Xeon, Scalable Xeon itp.
Warto zauważyć, że Firma Intel została powiadomiona o luce we wrześniu 2018 r aw lipcu 2019 r. udostępniono prototypowy exploit, który wykazał wyciek danych między rdzeniami procesora, ale opracowanie rozwiązania zostało opóźnione ze względu na złożoność implementacji.
W dzisiejszej proponowanej aktualizacji mikrokodu problem jest blokowany przez zmianę zachowania instrukcji RDRAND, RDSEED i EGETKEY, aby nadpisać dane we współdzielonym buforze, aby zapobiec osadzaniu się w nim resztkowych informacji.
Ponadto zawieszenie dostępu do bufora obowiązuje do momentu zakończenia operacji odczytu i zapisu.
Efekt uboczny tej ochrony to wzrost opóźnień gdy wykonywane są polecenia RDRAND, RDSEED i EGETKEY oraz zmniejszenie wydajności przy próbie jednoczesnego wykonania tych instrukcji na różnych procesorach logicznych. Te funkcje mogą niekorzystnie wpływać na wydajność niektórych aplikacji.
źródło: https://www.vusec.net
Nagłówek nie jest zrozumiany, gdzie idą trzy punkty, powinien być przecinek i tak, to „tak” ma akcent.