Naukowcy z Georgia Institute of Technology, University of Michigan i Ruhr University opracowali technikę ataku iLeakage, która pozwala wykorzystać lukę w procesorach ARM Apple z serii A i M poprzez otwarcie specjalnie zaprojektowanej strony w przeglądarce. Przygotowane przez badaczy prototypy exploitów pozwalają, uruchamiając kod JavaScript w przeglądarce, poznać zawartość stron otwieranych w innych zakładkach.Wykazano m.in. możliwość ustalenia tekstu listu otwartego w zakładce Gmail, obejrzyj YouTube historię i odzyskaj hasło wprowadzone przez menedżera haseł LastPass do formularza logowania.Instagram. Atak dotyczy przeglądarki Safari na systemach z macOS oraz dowolnych przeglądarek na platformie iOS (reguły Apple wymagają, aby wszystkie przeglądarki iOS korzystały wyłącznie z silnika systemu WebKit, który jest wspólny dla Safari).
Chociaż atak dotyczy tylko produktów Apple, oferuje ciekawy sposób na ominięcie ograniczeń rozdzielczości timera w silniku WebKit, co może być potencjalnie przydatne do ominięcia podobnych ograniczeń w innych przeglądarkach. Podatność zidentyfikowana w chipach Apple M1 i M2 przypomina klasyczną lukę Spectre v1 i prowadzi także do wycieku zawartości pamięci podczas wykonywania operacji w trybie spekulacyjnym, która w przypadku błędnej prognozy jest odrzucana przez procesor, ale ślady ich wykonania są przechowywane w pamięci podręcznej procesora.
W tej metodzie ataku wykonanie spekulatywne umożliwiło utworzenie prymitywu służącego do odczytywania dowolnych 64-bitowych wskaźników w przestrzeni adresowej procesu odpowiedzialnego za renderowanie zawartości stron w przeglądarce. Aby uzyskać dostęp do przestrzeni adresowej procesu renderowania cudzej witryny, zastosowano trik polegający na otwarciu badanej strony obcej w wyskakującym oknie za pomocą metody JavaScript window.open(). W tym przypadku strona została otwarta nie w oddzielnym procesie, ale w tym samym procesie z kodem atakującego.
Ze względów bezpieczeństwa silnik WebKit pozwala na pracę JavaScriptu tylko ze spakowanymi 35-bitowymi wskaźnikami. Aby zapewnić dostęp do całej przestrzeni adresowej procesu i ominąć 35-bitowy limit, badacze zastosowali technikę Type Confusion, aby zmusić silnik JavaScript do przetworzenia obiektu o nieprawidłowym typie. Podczas przetwarzania w silniku specjalnie zaprojektowanego obiektu JavaScript tworzone są warunki, które prowadzą do spekulatywnego wykonania instrukcji uzyskujących dostęp do tablicy.
Ponieważ typ obiektu nie jest zgodny z typem przetwarzanej tablicy, w normalnych warunkach takie akcje są blokowane, dlatego kod ataku Type Confusion umieszczany jest w warunkowym bloku „if”, który w normalnych warunkach nie jest aktywowany , ale jest wykonywany w trybie spekulatywnym, jeśli procesor błędnie przewidzi dalsze rozgałęzienia. W rezultacie procesor uzyskuje dostęp spekulacyjny do wygenerowanego 64-bitowego wskaźnika, ale wycofuje stan po stwierdzeniu nieudanej predykcji. W takim przypadku ślady wykonania spekulacyjnego są gromadzone we współdzielonej pamięci podręcznej i można je przywrócić za pomocą metod określania zawartości pamięci podręcznej za pośrednictwem kanałów bocznych.
Aby wyodrębnić dane z pamięci podręcznej procesora L1 pozostałej po operacjach spekulacyjnych, w ataku wykorzystuje się modyfikację metody pLRU (pseudo Least Ostatnio Używane), zaproponowaną wcześniej przez Google. W tym przypadku oryginalna metoda pLRU opiera się na pomiarze opóźnień w dostępie do danych, których różnica pozwala ocenić, czy dana sekwencja znajduje się w pamięci podręcznej procesora (jeśli dane są buforowane, operacja jest wykonywana szybciej, a jeśli nie, wolniej). Aby zabezpieczyć się przed sondowaniem pamięci podręcznej procesora w nowoczesnych przeglądarkach, dokładność licznika czasu została znacznie zmniejszona do poziomu, który nie pozwala na wykrycie różnic.
Aby przezwyciężyć ograniczenie dokładności zegara w ataku iLeakage, zaproponowano technikę określania obecności lub braku danych w pamięci podręcznej przy użyciu warunków wyścigu. Istotą metody jest jednoczesne uruchomienie dwóch wątków – głównego i referencyjnego. Wątek odniesienia zawiera sekwencję instrukcji, które są wykonywane w określonym czasie odniesienia. Na samym początku wykonywania wątku referencyjnego zmienna współdzielona z wątkiem głównym jest ustawiana na 1, a po wykonaniu instrukcji zmienna jest resetowana do zera. Zatem zmienna współdzielona ma wartość 1 tylko przez pewien krótki czas.
Główny wątek inicjuje cykl ustalania danych w pamięci podręcznej metodą pLRU. Oznaką obecności lub braku sprawdzanych danych w pamięci podręcznej nie jest pomiar czasu przez timer, ale stan zmiennej wspólnej po sprawdzeniu. Jeżeli zmienna ma wartość 1, to operacja zakończyła się szybciej niż kod referencyjny został wykonany w wątku równoległym, czyli tj. dane zostały podane z pamięci podręcznej. Jeżeli zmienna zawiera wartość 0, to operacja trwała stosunkowo długo ze względu na brak danych w pamięci podręcznej, a kod referencyjny w wątku równoległym miał czas na pełne przetworzenie.
Dokładność proponowanej metody określania zawartości pamięci podręcznej waha się od 90% do 99%, a wydajność wyznaczania danych wynosi od 23 do 34 bajtów na sekundę, w zależności od procesora i urządzenia. Przed przeprowadzeniem ataku wymagana jest kalibracja kodu referencyjnego, co zajmuje około pięciu minut. Po zakończeniu kalibracji dla bieżącego systemu wyodrębnienie ciągu 64 znaków zajmuje około 30 sekund.
Dodatkowo możemy odnotować publikację prototypowego exploita, który wykorzystuje lukę Zenbleed w procesorach AMD opartych na mikroarchitekturze Zen2 do wydobywania danych przetwarzanych w innych procesach podczas otwierania strony z exploitem w przeglądarce Chrome. Oprócz luki Zenbleed (CVE-2023-20593) exploit wykorzystuje także lukę CVE-2023-3079 w silniku V8, naprawioną w Chrome 115.
Źródło: opennet.ru