Błąd AMD “Zenbleed” wycieka dane z procesorów Ryzen, EPYC: Większość poprawek wejdzie w czwartym kwartale tego roku

Tavis Ormandy, badacz z Google Information Security, opublikował dziś informację o nowej luce, którą niezależnie znalazł w procesorach Zen 2 firmy AMD. Luka “Zenbleed” obejmuje cały stos produktów Zen 2, w tym procesory AMD EPYC dla centrów danych i procesory Ryzen 3000/4000/5000, umożliwiając kradzież chronionych informacji z procesora, takich jak klucze szyfrowania i loginy użytkowników. Atak nie wymaga fizycznego dostępu do komputera lub serwera i może być choćby wykonany za pośrednictwem javascript na stronie internetowej.

AMD nie miało gotowego poradnika w momencie publikacji, ale firma dodała biuletyn AMD-SB-7008 kilka godzin później. AMD ma już gotowe łatki dla swoich procesorów EPYC 7002 “Rome”, ale nie będzie łatać swoich konsumenckich układów Zen 2 Ryzen 3000, 4000 i niektórych układów z serii 5000 do listopada i grudnia tego roku. Procesory AMD używane w PS5, Xbox Series X i S oraz Steam Deck są również zasilane przez układy Zen 2, ale nie jest jasne, czy są one zagrożone.

AMD nie podało konkretnych szczegółów dotyczących wpływu na wydajność, ale wydało następujące oświadczenie:

“Jakikolwiek wpływ na wydajność będzie się różnił w zależności od obciążenia i konfiguracji systemu. AMD nie jest świadome żadnego znanego wykorzystania opisanej luki poza środowiskiem badawczym”.

Oświadczenie AMD sugeruje, iż łatki będą miały pewien wpływ na wydajność, ale będziemy musieli przeprowadzić niezależne testy porównawcze, gdy pojawią się łatki dla konsumenckich produktów Ryzen. W międzyczasie poproszono AMD o wszelkie dane liczbowe, którymi może się podzielić.

Luka Zenbleed została zgłoszona jako CVE-2023-20593 i umożliwia eksfiltrację (kradzież) danych z szybkością 30kb na rdzeń na sekundę, zapewniając w ten sposób odpowiednią przepustowość do kradzieży poufnych informacji przepływających przez procesor. Atak ten działa na całym oprogramowaniu uruchomionym na procesorze, w tym na maszynach wirtualnych, środowiskach sandbox, kontenerach i procesach. Zdolność tego ataku do odczytywania danych z maszyn wirtualnych jest szczególnie groźna dla dostawców usług w chmurze i tych, którzy korzystają z instancji w chmurze.

Atak można przeprowadzić poprzez nieuprzywilejowane wykonanie dowolnego kodu. Ormandy opublikował repozytorium badań bezpieczeństwa i kod exploita. Atak działa poprzez manipulowanie plikami rejestru w celu wymuszenia błędnego przewidywanego polecenia (co oznacza, iż wykorzystuje spekulacyjny silnik wykonawczy), jak opisano poniżej:

“Błąd działa w ten sposób, iż najpierw trzeba uruchomić coś, co nazywa się XMM Register Merge Optimization2, po czym następuje zmiana nazwy rejestru i błędnie przewidziany vzeroupper. Wszystko to musi się wydarzyć w ściśle określonym oknie, aby zadziałało.

Wiemy już, iż podstawowe operacje, takie jak strlen, memcpy i strcmp, będą korzystać z rejestrów wektorowych – możemy więc skutecznie szpiegować te operacje w dowolnym miejscu systemu! Nie ma znaczenia, czy mają one miejsce w innych maszynach wirtualnych, piaskownicach, kontenerach, procesach, czy gdziekolwiek indziej!

Działa to, ponieważ plik rejestru jest współdzielony przez wszystko na tym samym rdzeniu fizycznym. W rzeczywistości dwa hiperwątki współdzielą choćby ten sam fizyczny plik rejestru” – mówi Ormandy.

AMD opisuje exploit znacznie prościej, mówiąc: “W określonych okolicznościach mikroarchitektonicznych rejestr w procesorach “Zen 2″ może nie zostać poprawnie zapisany na 0. Może to spowodować, iż dane z innego procesu i/lub wątku będą przechowywane w rejestrze YMM, co może pozwolić atakującemu na potencjalny dostęp do poufnych informacji”.

Ormandy twierdzi, iż błąd można załatać programowo dla wielu systemów operacyjnych (np. Windows – “można ustawić bit kurczaka DE_CFG[9]”), ale może to spowodować spadek wydajności. Ormandy twierdzi, iż zdecydowanie zaleca się pobranie aktualizacji mikrokodu, ale jego post zawiera również przykłady programowych środków zaradczych dla innych systemów operacyjnych.

Oto lista procesorów, których dotyczy problem, a także harmonogram wydawania wersji AGESA dla producentów OEM: