4 lata od wykrycia luki w zabezpieczeniach, „Spectre”

Od pierwszej publikacji badań dotyczących Spectre i Meltdown — luk sprzętowych w nowoczesnych procesorach — minęły cztery lata. Przez ten czas odkryto kilka podobnych luk, które potencjalnie mogą umożliwiać wyciek poufnych danych. Badacze pokazali przykłady ataków, które je wykorzystują, chociaż większość z nich raczej nie zostanie wykorzystana w świecie rzeczywistym. W tym poście przyjrzymy się, jak dziś wygląda problem luk w zabezpieczeniach sprzętu i jakie są potencjalne szanse na wykorzystanie ich do atakowania firm.

Kilka wariantów luki Spectre

Pierwsza informacja o wykryciu zagrożeń pojawiła się w sierpniu 2018 r. Ujawniło wówczas trzy luki: Spectre v1 i v2 oraz Meltdown. Luki te mają kilka wspólnych cech:

• Ich wykorzystanie zwykle wiąże się z wykonaniem szkodliwego kodu w podatnym na ataki systemie, choć obejmuje wykorzystanie niskiego poziomu uprawnień. Najbardziej niebezpieczną opcją jest atak za pośrednictwem przeglądarki, gdy ofiara wejdzie na „zainfekowaną” stronę internetową.
• Praktyczne wykorzystanie tych luk wymaga spełnienia szeregu warunków — przede wszystkim kod atakowanej aplikacji musi umożliwiać wyciek danych, posiadać tzw. „gadżet”, do którego dostęp umożliwia atak.
• Sam wyciek danych odbywa się kanałami bocznymi i z tego powodu przebiega on dość powoli.
• Udany atak może nie pozostawić żadnych śladów nieautoryzowanego dostępu do danych.

Szczególne zainteresowanie tą pozornie teoretyczną pracą naukową wzbudził punkt ostatni. We wszystkich przypadkach badacze wykorzystali system przewidywania gałęzi. Mechanizm ten został wprowadzony ponad 20 lat temu, pozwala zwiększyć wydajność poprzez wykonanie zestawu instrukcji, zanim takie polecenie wyda program. Jeśli prognoza była poprawna, zasoby procesora zostaną wykorzystywane efektywniej; jeśli prognoza była błędna, obliczenia zostaną odrzucone.

Eksperyment mający stanowić dowód słuszności koncepcji dla Spectre v1 pokazał, że procesor odczyta dane, które powinny być niedostępne dla programu. Są one przechowywane w pamięci podręcznej i można je stamtąd pobrać za pośrednictwem kanałów bocznych. Mechanizm ten był uznawany za bezpieczny, ponieważ błędnie odczytane „tajne dane” nie były przesyłane do programu. Ale badacze znaleźli kilka sposobów na niebezpośrednie odczytanie ich.

Po opublikowaniu informacji na temat prac dotyczących Spectre i Meltdown odkryto kilka podobnych luk. Badacze nadal poszukują nowych metod zdobywania tajnych danych przy użyciu luk w zabezpieczeniach procesorów. Tabela podsumowująca opracowana przez firmę Intel zawiera — oprócz tu opisywanych — ponad 20 innych problemów.

Jak zapewnić sobie ochronę przed Spectre?

Teoretycznie istnieją trzy sposoby na zmniejszenie możliwości wykorzystania luki w zabezpieczeniach procesora: dostawcy mogą wydać aktualizację mikrokodu dla istniejących procesorów, mogą zmodyfikować nowe procesory lub próbować rozwiązać problem za pomocą aktualizacji oprogramowania. Działania wymiernie łagodzące ryzyko często wymagają połączenia oprogramowania układowego i aktualizacji oprogramowania. Nowy mikrokod eliminujący część luk w zabezpieczeniach jest dostępny dla procesorów Intel od generacji Haswell 2013. Rozwiązania sprzętowe zostały po raz pierwszy zaimplementowane w ósmej generacji procesorów Intela, a także w procesorach AMD Zen 2.

Rozwiązania programowe mogą być dość trudne do wprowadzenia: przykładem są tu możliwe modyfikacje w jądrze Linuksa mające ochronić przed oboma wariantami luki Spectre. Badacze omówili wiele środków ochronnych, które różnią się w zależności od celu i zadań konkretnych systemów — w tym całkowite wyłączenie spekulacyjnego wykonywania kodu, co skutkowałoby poważnym obniżeniem wydajności procesorów.

W przypadku większości organizacji, których model biznesowy zależy od wydajności dużej liczby używanych serwerów, taki spadek byłby najbardziej zauważalnym wpływem środków ochrony przed luką Spectre. Na stronie internetowej organizacji Phoronix został opublikowany przeprowadzony stosunkowo niedawno test porównawczy, którego celem było sprawdzenie wydajności różnych aplikacji serwerowych. Okazało się, że po aktywowaniu w systemie operacyjnym Linux wszystkich środków ochrony spadek wydajności wynosił średnio 25%.

Realne ataki i dowody słuszności koncepcji

Pomimo dużej liczby rodzajów ataków zagrożenie związane z kradzieżą danych za pomocą luki Spectre nadal jest w fazie teorii. Chociaż w każdym badaniu opisywany jest jakiś kod, który może doprowadzić do wycieku, nie oznacza to, że może on zostać użyty na prawdziwym systemie. Do typowych ograniczeń wersji demonstracyjnych i przedstawianych jako dowody słuszności koncepcji należą następujące fakty:

• Prezentują one losowy wyciek danych, który może nie mieć uzasadnienia praktycznego — może obejmować on przypadkowe informacje, do których atakujący wcześniej nie miał dostępu.
• Badacze stworzyli idealne warunki do ataku, na przykład mieli nieograniczony dostęp do systemu. W takim przypadku nie jest konieczne stosowanie skomplikowanych metod zdobywania danych.
• Pokazuje możliwy do przeprowadzenia w rzeczywistości wyciek danych, ale w bardzo mało prawdopodobnych warunkach.

Najbardziej imponującą pracą teoretyczną (pod względem możliwych konsekwencji) jest atak NetSpectre. Badacze zademonstrowali zdalne wykorzystanie luki i eksfiltrację danych z prędkością od 15 do 60 bitów na godzinę. Ograniczenia tego ataku są przewidywalne: niewielka szybkość transmisji danych, eksfiltrowane dane zawierają ogromną ilość informacji nieprzydatnych, a także obecność „we właściwym miejscu” podatnego na ataki kodu na zaatakowanym serwerze.

W zeszłym roku pokazano dwa ataki praktyczne, jak najbardziej zbliżone do warunków rzeczywistych. W marcu firma Google zaprezentowała koncepcję leaky.page: stronę internetową, która może wyodrębniać dane z pamięci RAM. We wrześniu zademonstrowano atak Spook.js na najnowszą (na czas prowadzenia badania) wersję przeglądarki Google Chrome (92) zapewniającą ochronę przed luką Spectre poprzez izolację stron internetowych w oddzielnych procesach przeglądarki. Ta metoda pozwoliła na prawdziwą kradzież danych: badacze uzyskali dostęp do danych logowania do sieci społecznościowej, danych w menedżerze haseł i obrazu przesłanego przez użytkownika do chmury prywatnej. Ale we wszystkich tych przypadkach wyciek danych wymagał posiadania „zainfekowanej” strony znajdującej się w tej samej domenie. Na przykład kradzież hasła do konta w serwisie Tumblr polega na przesłaniu szkodliwego kodu w języku JavaScript na inną stronę w tej samej sieci społecznościowej.

Jak duże jest niebezpieczeństwo?

Luka Spook.js została zneutralizowana poprzez łatkę do oprogramowania dla przeglądarki Google Chrome, dlatego w tej chwili nie istnieje bezpośrednie zagrożenie wykorzystania luk Spectre w warunkach rzeczywistych. Wszystkie znane ataki są niezwykle złożone i wymagają od atakującego dysponowania ponadprzeciętnymi umiejętnościami.

Większość luk, dla których utworzono realistyczne dowody słuszności koncepcji, została załatana, ale nawet gdy poprawki te nie są zainstalowane, wykorzystanie takich podatności wymaga spełnienia wielu warunków. Mimo że doniesienia medialne o prawdziwych „exploitach dla luki Spectre” nie zostały potwierdzone, dostawcy zabezpieczeń na wszelki wypadek dodali narzędzia służące do wykrywania znanych ataków, więc dostępne mechanizmy wykrywania szkodliwego oprogramowania najprawdopodobniej już chronią firmy.

Nie powinniśmy jednak całkowicie ignorować luki Spectre; badania nad nią muszą trwać. Istnieje niewielka szansa, że za jakiś czas zostanie odkryty „najgorszy scenariusz”: atak, który nie wymaga instalacji szkodliwego oprogramowania, pozwala na wyciek danych i przy tym nie pozostawia po sobie śladu.

Teoretycznie, jeśli dane mają dużą wartość, przeprowadzenie ataku ukierunkowanego z wykorzystaniem luk sprzętowych jest możliwe. Ochrona przed takimi zagrożeniami wymaga poważnych inwestycji w identyfikację potencjalnych wektorów ataku, przestrzegania zaleceń twórców systemów operacyjnych i wdrożenia ochrony nawet kosztem poważnego spadku wydajności. Jednak w przypadku większości nawet dużych firm wystarczy, aby zaufały one twórcom oprogramowania i systemów operacyjnych, producentom procesorów i rozwiązań zabezpieczających.