Google opublikowało kilka prototypowych exploitów, które demonstrują możliwość wykorzystania luk klasy Spectre podczas wykonywania kodu JavaScript w przeglądarce, omijając wcześniej dodane metody ochrony. Exploity te mogą służyć do uzyskania dostępu do pamięci procesu przetwarzającego zawartość internetową w bieżącej karcie. W celu przetestowania exploita uruchomiono witrynę leaky.page, a kod opisujący logikę działania został opublikowany w serwisie GitHub.
Proponowany prototyp ma na celu przeprowadzenie ataku na systemy z procesorami Intel Core i7-6500U w środowisku z Linux i Chrome 88. Aby zastosować exploit w innych środowiskach, wymagane są modyfikacje. Metoda wykorzystania exploita nie jest specyficzna dla procesorów Intel; po odpowiedniej adaptacji potwierdzono, że działa on w 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 przeglądarkach opartych na Chromium.
W środowisku opartym na standardowych procesorach Chrome 88 i Intel Skylake udało się uzyskać wyciek danych z procesu odpowiedzialnego za przetwarzanie treści internetowych w bieżącej karcie przeglądarki Chrome (proces renderera) z prędkością 1 kilobajta na sekundę. Dodatkowo opracowano alternatywne prototypy, na przykład exploit, który pozwala, kosztem obniżonej stabilności, zwiększyć szybkość wycieku do 8 kB/s przy użyciu timera performance.now() z dokładnością 5 mikrosekund (0.005 milisekundy). Przygotowano również wariant działający z dokładnością timera jednej milisekundy, który mógłby zostać wykorzystany do organizacji dostępu do pamięci innego procesu z prędkoś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 wymaganego do przywrócenia danych pozostawionych w pamięci podręcznej procesora w wyniku spekulatywnego wykonania instrukcji procesora. Druga część określa układ pamięci używany do alokacji tablicy JavaScript.
Trzecia część bezpośrednio wykorzystuje lukę w zabezpieczeniach Spectre w celu ustalenia zawartości pamięci bieżącego procesu poprzez stworzenie warunków do spekulatywnego wykonania pewnych operacji, których wynik jest odrzucany przez procesor po ustaleniu nieudanej predykcji, ale ślady wykonania są deponowane w pamięci podręcznej i mogą zostać przywrócone za pomocą metod ustalania zawartości pamięci podręcznej przez kanały boczne, analizując zmianę czasu dostępu do danych buforowanych i niebuforowanych.
Proponowana technika eksploatacji eliminuje potrzebę stosowania precyzyjnych timerów dostępnych za pośrednictwem interfejsu API performance.now() oraz typu SharedArrayBuffer, który umożliwia tworzenie tablic w pamięci współdzielonej. Eksploit obejmuje gadżet Spectre, który powoduje kontrolowane wykonywanie kodu spekulatywnego, oraz analizator wycieków kanału bocznego, który wykrywa dane z pamięci podręcznej uzyskane podczas wykonywania spekulatywnego.
Gadżet został zaimplementowany za pomocą tablicy JavaScript, która próbuje uzyskać dostęp do obszaru poza granicami bufora, wpływając na stan bloku przewidywania rozgałęzień ze względu na obecność kontroli rozmiaru bufora dodanej przez kompilator (procesor, działając naprzód, spekulatywnie wykonuje dostęp, ale wycofuje stan po sprawdzeniu). Aby przeanalizować zawartość pamięci podręcznej w warunkach niedostatecznej dokładności timera, zaproponowano metodę, która oszukuje strategię usuwania pamięci podręcznej Tree-PLRU stosowaną w procesorach i pozwala, poprzez zwiększenie liczby cykli, znacząco zwiększyć różnicę czasu między zwracaniem wartości z pamięci podręcznej a sytuacją, gdy wartość ta nie znajduje się w pamięci podręcznej.
Należy zauważyć, że Google opublikował prototyp exploita, aby zademonstrować realizm ataków wykorzystujących luki 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 gruntownej przebudowy proponowanego prototypu niemożliwe jest stworzenie uniwersalnych exploitów, gotowych nie tylko do demonstracji, ale także do powszechnego użytku.
Aby zmniejszyć ryzyko, właścicielom witryn zaleca się korzystanie z niedawno wdrożonych nagłówków: Cross-Origin Opener Policy (COOP), Cross-Origin Embedder Policy (COEP), Cross-Origin Resource Policy (CORP), Fetch Metadata Request, X-Frame-Options, X-Content-Type-Options oraz SameSite Cookie. Mechanizmy te nie chronią bezpośrednio przed atakami, ale pozwalają na izolowanie danych witryny przed wyciekami do procesów, w których może być wykonywany 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 karcie). Głównym założeniem jest oddzielenie wykonywania kodu witryny w różnych procesach od kodu stron trzecich uzyskanego z niezaufanych źródeł, takich jak kod dołączony za pośrednictwem ramki iframe.
Źródło: opennet.ru
