Google opublikowało kilka prototypów exploitów pokazujących możliwość wykorzystania luk klasy Spectre podczas wykonywania kodu JavaScript w przeglądarce z pominięciem dodanych wcześniej metod ochrony. Exploity mogą zostać wykorzystane do uzyskania dostępu do pamięci procesu przetwarzającego zawartość sieciową w bieżącej zakładce. Aby przetestować działanie exploita, uruchomiono stronę internetową Leaky.page, a kod opisujący logikę pracy zamieszczono na GitHubie.
Proponowany prototyp przeznaczony jest do atakowania systemów z procesorami Intel Core i7-6500U w środowisku z systemem Linux i Chrome 88. Aby wykorzystać exploit w innych środowiskach, wymagane są modyfikacje. Sposób wykorzystania nie jest specyficzny dla procesorów Intela - po odpowiedniej adaptacji potwierdzono, że exploit działa na systemach z procesorami innych producentów, w tym Apple M1 opartym na architekturze ARM. Po drobnych modyfikacjach exploit działa również w innych systemach operacyjnych i innych przeglądarkach opartych na silniku Chromium.
W środowisku opartym na standardowych procesorach Chrome 88 i Intel Skylake możliwy był wyciek danych z procesu odpowiedzialnego za przetwarzanie treści internetowych w aktualnej zakładce Chrome (proces renderera) z prędkością 1 kilobajta na sekundę. Dodatkowo opracowano alternatywne prototypy, np. exploit pozwalający, kosztem zmniejszenia stabilności, zwiększyć szybkość wycieków do 8kB/s przy wykorzystaniu timera performance.now() z dokładnością do 5 mikrosekund (0.005 milisekundy) ). Przygotowano także wersję pracującą z timerem z dokładnością do jednej milisekundy, która mogła służyć do organizowania dostępu do pamięci innego procesu z szybkością około 60 bajtów na sekundę.
Opublikowany kod demonstracyjny składa się z trzech części. Pierwsza część kalibruje timer w celu oszacowania czasu wykonania operacji wymaganych do przywrócenia danych pozostałych w pamięci podręcznej procesora w wyniku spekulatywnego wykonania instrukcji procesora. Druga część określa układ pamięci używany podczas alokacji tablicy JavaScript.
Trzecia część bezpośrednio wykorzystuje lukę Spectre w celu określenia zawartości pamięci bieżącego procesu w wyniku stworzenia warunków do spekulatywnego wykonania określonych operacji, których wynik jest odrzucany przez procesor po ustaleniu nieudanej przewidywania, ale ślady wykonania są zapisywane w ogólnej pamięci podręcznej i można je przywrócić przy użyciu metod określania zawartości pamięci podręcznej przez kanały stron trzecich, które analizują zmiany w czasie dostępu do danych buforowanych i niezapisanych w pamięci podręcznej.
Zaproponowana technika eksploatacji pozwala obejść się bez bardzo precyzyjnych timerów dostępnych poprzez API performance.now() oraz bez obsługi typu SharedArrayBuffer, który pozwala na tworzenie tablic w pamięci współdzielonej. Exploit obejmuje gadżet Spectre, który powoduje kontrolowane spekulatywne wykonanie kodu, oraz analizator wycieków z kanału bocznego, który wykrywa dane zapisane w pamięci podręcznej uzyskane podczas wykonywania spekulatywnego.
Gadżet jest zaimplementowany przy użyciu tablicy JavaScript, w której podejmowana jest próba dostępu do obszaru znajdującego się poza granicami bufora, co wpływa na stan bloku przewidywania rozgałęzień ze względu na obecność kontroli rozmiaru bufora dodanej przez kompilator (procesor, patrząc w przyszłość, spekulacyjnie wykonuje dostęp, ale po sprawdzeniu cofa stan). Do analizy zawartości pamięci podręcznej w warunkach niewystarczającej dokładności timera zaproponowano metodę, która oszukuje stosowaną w procesorach strategię eksmisji pamięci podręcznej Tree-PLRU i pozwala poprzez zwiększenie liczby cykli znacznie zwiększyć różnicę czasu przy powrocie wartość z pamięci podręcznej i gdy nie ma żadnej wartości w pamięci podręcznej.
Należy zauważyć, że Google opublikowało prototyp exploita, aby wykazać wykonalność ataków z wykorzystaniem luk klasy Spectre i zachęcić twórców stron internetowych do stosowania technik minimalizujących ryzyko takich ataków. Jednocześnie Google uważa, że bez znaczących przeróbek proponowanego prototypu nie da się stworzyć uniwersalnych exploitów, gotowych nie tylko do demonstracji, ale także do powszechnego użycia.
Aby zmniejszyć ryzyko, zachęca się właścicieli witryn do korzystania z niedawno wdrożonych zasad otwierania między źródłami nagłówków (COOP), zasad osadzania między źródłami (COEP), zasad zasobów między źródłami (CORP), żądania pobierania metadanych, X-Frame- Opcje, X -Opcje typu zawartości i Plik cookie SameSite. Mechanizmy te nie chronią bezpośrednio przed atakami, ale pozwalają odizolować dane serwisu przed wyciekiem do procesów, w których może zostać wykonany kod JavaScript atakującego (wyciek następuje z pamięci bieżącego procesu, który oprócz kodu atakującego , może również przetwarzać dane z innej witryny otwartej w tej samej zakładce). Główną ideą jest oddzielenie wykonywania kodu witryny w różnych procesach od kodu strony trzeciej otrzymanego z niewiarygodnych źródeł, na przykład zawartego w ramce iframe.
Źródło: opennet.ru