Badacze z firmy Bitdefender nową lukę () w mechanizmie spekulacyjnego wykonania instrukcji nowoczesnych procesorów, która zyskała nazwę SWAPGS, odpowiadającą nazwie instrukcji procesora wywołującej problem. Luka ta umożliwia nieuprzywilejowanemu atakującemu określenie zawartości obszarów pamięci jądra lub uruchomionych maszyn wirtualnych. Problem ten w procesorach Intel (x86_64) oraz częściowo w procesorach AMD, w których nie ujawnia się główny wektor ataku. Wcześniej wdrożone metody przeciwdziałania lukom Spectre i Meltdown nie chronią przed atakiem SWAPGS w przypadku procesorów Intel, ale dla systemów Linux, ChromeOS, Android i Windows już zaproponowano poprawki.
Luka ta należy do klasy Spectre v1 i opiera się na idei odzyskiwania danych z pamięci podręcznej procesora, które pozostały po spekulacyjnym wykonaniu instrukcji. Bloki przewidywania skoków nowoczesnych procesorów dla zwiększenia wydajności stosują wstępne wykonywanie niektórych instrukcji, które najprawdopodobniej zostaną wykonane, jednak zanim obliczone zostaną wszystkie czynniki decydujące o ich wykonaniu (na przykład, gdy warunki skoku lub parametry dostępu nie zostały jeszcze obliczone). Jeśli prognoza nie jest potwierdzona, procesor odrzuca wynik spekulacyjnego wykonania, jednak dane przetworzone w jego trakcie osiadają w pamięci podręcznej procesora i mogą zostać odzyskane za pomocą metod określania zawartości pamięci podręcznej przez kanały boczne, analizujących zmiany czasu dostępu do danych w pamięci podręcznej i nie w pamięci podręcznej.
Charakter nowego ataku polega na wykorzystaniu wycieku, który występuje w trakcie spekulacyjnego wykonania instrukcji SWAPGS, stosowanej w systemach operacyjnych do zamiany wartości rejestru GS podczas przechodzenia kontroli z przestrzeni użytkownika do jądra systemu operacyjnego (wartość GS stosowana w przestrzeni użytkownika jest zastępowana wartością używaną w operacjach w jądrze). W jądrze Linux w GS przechowywany jest wskaźnik per_cpu, wykorzystywany do uzyskiwania dostępu do danych jądra, a w przestrzeni użytkownika wskaźniki do TLS (Thread Local Storage).
Aby uniknąć podwójnego wywołania instrukcji SWAPGS podczas ponownego dostępu do jądra z przestrzeni jądra lub gdy wykonywany jest kod, który nie wymaga zmiany rejestru GS, przed instrukcją przeprowadzana jest kontrola i warunkowe przejście. Mechanizm wykonania spekulacyjnego z góry przechodzi do wykonania kodu z instrukcją SWAPGS, nie czekając na wynik kontroli, a jeśli wybrana gałąź nie została potwierdzona, wynik jest odrzucany. Tak więc, może wystąpić sytuacja, w której spekulacyjnie wybrana gałąź nie przewiduje wykonania SWAPGS, ale w trakcie spekulacyjnego wykonania wartość rejestru GS zostanie zmieniona przez instrukcję SWAPGS i użyta w zależnych operacjach z pamięcią, które osiedlają się w pamięci podręcznej CPU.
Badacze zaproponowali dwa scenariusze ataku, dla których przygotowano prototypy exploitów. Pierwszy scenariusz opiera się na sytuacji, w której instrukcja SWAPGS nie jest wykonywana spekulacyjnie, choć jest używana podczas rzeczywistego wykonania, a drugi – odwrotnie, gdy instrukcja SWAPGS jest wykonywana spekulacyjnie, choć faktycznie nie powinna. Dla każdego scenariusza przewidziano dwa warianty eksploatacji: atakujący może określić wartość pod określonym adresem w obszarze jądra, a atakujący może przeprowadzić poszukiwanie określonej wartości pod losowymi adresami w jądrze. Przeprowadzenie ataku zajmuje dużo czasu, a do zorganizowania wycieku może być konieczne wykonanie exploita przez kilka godzin.
W jądrze Linux problem poprzez zmianę logiki wywołania instrukcji SWAPGS (blokowanie wykonania spekulacyjnego), na wzór poprawek dotyczących innych podatności klasy Spectre v1. Zakłada się, że dodana ochrona w minimalnym stopniu wpłynie na wydajność typowych obciążeń roboczych. Opóźnienie występuje na etapie przełączania między przestrzenią użytkownika a jądrem, co może prowadzić do spadku wydajności, na przykład podczas intensywnego wykonywania wywołań systemowych z aplikacji lub częstej generacji NMI i przerwań.
Korekta wymaga zainstalowania aktualizacji jądra zarówno w głównym systemie, jak i w środowiskach gościnnych, po czym konieczne jest ponowne uruchomienie systemu. Aby wyłączyć zabezpieczenia w Linux, można użyć opcji „nospectre_v1”, która również wyłącza środki blokujące lukę SWAPGS. Korekta jest dostępna jako dla jądra Linux, które już zostało włączone w wersjach , , 4.14.137, 4.9.188 oraz 4.4.188. Aktualizacje dla dystrybucji Linux nie zostały jeszcze wydane (, , , , , ). W Windows problem został rozwiązany bez zbędnego rozgłosu w . Firma Google przygotowała poprawkę do jądra 4.19, dostarczanego w ChromeOS i .
Według oświadczenia badaczy z firmy Bitdefender, Intel został poinformowany o problemie już w sierpniu zeszłego roku. Problem postanowiono rozwiązać programowo, do skoordynowanej produkcji poprawki zaangażowano deweloperów z Microsoftu, Google oraz jądra Linux. Stare procesory Intela, przed Ivy Bridge, są znacznie trudniejsze do zaatakowania z powodu braku wsparcia dla instrukcji WRGSBASE, wykorzystanej w eksploicie. Systemy ARM, POWER, SPARC, MIPS oraz RISC-V nie są podatne na to zagrożenie, ponieważ nie obsługują instrukcji SWAPGS.
Problem zagraża głównie posiadaczom procesorów Intel —
na systemach AMD udało się odtworzyć jedynie drugi scenariusz ataku, ograniczający się do spekulatywnego przetwarzania podstawowej wartości rejestru GS, co można wykorzystać do wyszukiwania określonych wartości w losowych obszarach pamięci. W celu zablokowania tego wariantu ataku istniejące metody ochrony przed lukami Spectre v1.
Źródło: opennet.ru
