Google zaprezentował kilka dni temu różne prototypy exploitów które pokazują możliwość wykorzystania luk w zabezpieczeniach klasy Spectre podczas wykonywania kodu JavaScript w przeglądarce, bez przechodzenia przez metody bezpieczeństwa dodane powyżej.
Exploity można wykorzystać do uzyskania dostępu do pamięci procesu który przetwarza treści internetowe w bieżącej karcie. Aby przetestować działanie exploita, uruchomiona została strona nieszczelnej strony, a kod opisujący logikę operacji został opublikowany na GitHubie.
Proponowany prototyp jest przeznaczony do atakować systemy z Procesory Intel Core i7-6500U w środowisku Linux i Chrome 88, chociaż nie wyklucza to możliwości wprowadzenia zmian w celu wykorzystania exploita w innych środowiskach.
Metoda działania nie jest specyficzna dla procesorów Intel: po odpowiedniej adaptacji, Exploit został potwierdzony do działania na systemach z procesorami innych firm, w tym Apple M1 oparty na architekturze ARM. Po drobnych poprawkach exploit działa również na innych systemach operacyjnych i innych przeglądarkach opartych na silniku Chromium.
W środowisku opartym na standardowych procesorach Chrome 88 i Intel Skylake uzyskaliśmy wyciek danych z procesu odpowiedzialnego za renderowanie treści internetowych na aktualnej karcie Chrome (proces renderowania) z prędkością 1 kilobajta na sekundę. Ponadto opracowano alternatywne prototypy, na przykład exploit, który pozwala kosztem zmniejszonej stabilności zwiększyć szybkość wycieku do 8kB / s przy użyciu timera performance.now () z dokładnością do 5 mikrosekund (0.005 milisekundy) ). Przygotowano również wariant działający z dokładnością czasową do jednej milisekundy, który mógłby służyć do organizowania 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ęść skalibruj stoper, aby oszacować czas pracy operacji niezbędnych do odzyskania danych, które pozostają w pamięci podręcznej procesora w wyniku spekulatywnego wykonania instrukcji procesora.
- Druga część Definiuje układ pamięci używany podczas przydzielania tablicy JavaScript.
- Trzecia część bezpośrednio wykorzystuje lukę Spectre do określenia zawartości pamięci bieżącego procesu w wyniku stworzenia warunków do spekulacyjnego wykonywania pewnych operacji, których wynik jest odrzucany przez procesor po określeniu nieudanej prognozy, ale ślady wykonania są rozliczane we współdzielonej pamięci podręcznej i można je przywrócić za pomocą metody określania zawartości pamięci podręcznej przy użyciu kanałów innych firm, które analizują zmianę czasu dostępu do danych przechowywanych w pamięci podręcznej i niebuforowanych.
Proponowana technika eksploatacji eliminuje precyzyjne zegary dostępne poprzez API performance.now () i bez wsparcia dla typu SharedArrayBuffer, co pozwala na tworzenie tablic w pamięci współdzielonej.
Exploit obejmuje urządzenie Spectre, które powoduje kontrolowane wykonanie kodu spekulacyjnego, oraz analizator wycieków w kanale bocznym, który określa, jakie dane zostały zapisane w pamięci podręcznej podczas wykonywania spekulacyjnego.
Gadżet jest zaimplementowany przy użyciu tablicy JavaScript, w którym podjęto próbę uzyskania dostępu do obszaru poza granicami bufora, co wpływa na stan bloku predykcji rozgałęzienia ze względu na obecność sprawdzania rozmiaru bufora dodanego przez kompilator (procesor spekulacyjnie wykonuje dostęp z wyprzedzeniem, ale po sprawdzeniu przywraca stan).
Aby przeanalizować zawartość pamięci podręcznej w warunkach niewystarczającej precyzji timera, zaproponowano metodę, która oszukuje strategię eksmisji danych pamięci podręcznej Tree-PLRU stosowaną w procesorach i pozwala, zwiększając liczbę cykli, znacznie zwiększyć różnicę czasu zwracania wartości z pamięci podręcznej i przy braku wartości w pamięci podręcznej.
Google opublikował prototyp exploita, aby pokazać wykonalność ataków za pomocą luk w zabezpieczeniach klasy Spectre i zachęcać twórców stron internetowych do korzystania z technik minimalizujących ryzyko takich ataków.
Jednocześnie Google uważa, że bez znaczącej rewizji proponowanego prototypu niemożliwe jest stworzenie uniwersalnych exploitów, które są gotowe nie tylko do demonstracji, ale także do powszechnego użytku.
źródło: https://security.googleblog.com